<kintel>
Does anyone have any idea why, with --view=wireframe --render=cgal, I would get circular vertices rather than square?
<kintel>
The only change I've made is how to request a GL context, and GL_POINT_SMOOTH is reported to be off.
<InPhase>
kintel: Hard to say because I usually don't get vertices.
<kintel>
haha, which is an equally interesting question :)
<kintel>
Feels like _some_ uninitialized state
<InPhase>
But, probably good that you're looking into it!
<kintel>
I was hoping not having to look into it, as this feels like a very annoying rabbit hole to get stuck in
<InPhase>
My working assumption was some sort of GL or driver differences. But that was a wild speculation.
<kintel>
..and I'm already many inception layers deep from wanting to experiment with modern OpenGL : /
<InPhase>
I'm going to say this I guess... Our wireframe stuff, even when it works, seems to be ridiculously ugly and has no aesthetic worth preserving. So if you were to, say, just scrap it and make something that's simpler and achieves the basic objectives, I doubt you'd get any complaints.
<InPhase>
Just throwing that out there as a possibility.
<kintel>
heh, yeah, my approach of green refactoring may not be worth pursuing across the board..
<kintel>
Out of curiosity, what's your graphics env like? (i.e. the interesting parts of openscad --info)
<kintel>
right, AMD, not something I can quickly replicate : /
<InPhase>
Yeah. I can run tests, but I cannot independently confirm myself. :)
<kintel>
Well, I can consistently flip between round and square points on the same hardware, renderer and GL version, depending on how I create a GL context. ..so I'm going to ignore this!
kintel has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
teepee has quit [Remote host closed the connection]
fling has quit [Remote host closed the connection]
fling has joined #openscad
<peepsalot>
does manifold do minkowski?
guso78 has joined #openscad
<peepsalot>
oh, i think i see, we still rely on CGAL to do the convex decomposition part
<peepsalot>
was confused for a second by an error saying that manifold failed, but the error came from CGAL source
ur5us_ has quit [Ping timeout: 250 seconds]
<peepsalot>
hmm, i'm finding manifold to be disturbingly non deterministic
use-value has quit [Ping timeout: 264 seconds]
ur5us_ has joined #openscad
ur5us_ has quit [Ping timeout: 250 seconds]
foul_owl has quit [Read error: Connection reset by peer]
foul_owl has joined #openscad
ToAruShiroiNeko has quit [Ping timeout: 264 seconds]
ToAruShiroiNeko has joined #openscad
qeed_ has quit [Quit: qeed_]
qeed has joined #openscad
<InPhase>
peepsalot: Well it is threaded, which resulted in some non-deterministic errors early, which is understandable as a bug structure. But is there anything non-deterministic left about the correctly functioning results?
<InPhase>
peepsalot: This would be problematic.
qeed_ has joined #openscad
qeed has quit [Ping timeout: 264 seconds]
snaked has quit [Quit: Leaving]
guso78 has quit [Ping timeout: 260 seconds]
califax has quit [Remote host closed the connection]
califax has joined #openscad
J2386764 has quit [Quit: Client closed]
J2386764 has joined #openscad
teepee_ has joined #openscad
teepee has quit [Ping timeout: 255 seconds]
teepee_ is now known as teepee
fling has quit [Remote host closed the connection]
pharonix71 has quit [Remote host closed the connection]
fling has joined #openscad
pharonix71 has joined #openscad
hrberg has joined #openscad
use-value has joined #openscad
admin__ has quit [Ping timeout: 248 seconds]
ur5us_ has joined #openscad
<peepsalot>
InPhase: I have a test script which does a lot of nested minkowski, it is intended to emulate offset in 3d. sometimes it succeeds, sometimes it fails on CGAL errors, sometimes it hangs seemingly indefinitely, sometimes memory usage explodes and it gets OOM killed
<peepsalot>
if things are too reliable try bumping fn to 20 or 24.
teepee_ has joined #openscad
teepee has quit [Ping timeout: 255 seconds]
teepee_ is now known as teepee
peeps[work] has joined #openscad
<peeps[work]>
oh and sometimes it only partially errors out of CGAL. so there's still incorrect geometry displayed, while other times it results in no top level object to render
guso78 has joined #openscad
kintel has joined #openscad
<kintel>
I figured out how to enable ssh on GitHub CI. However, once the server is open, it's technically possible for anyone to ssh into it.
<kintel>
On the positive side: It has to be activated by launch a workflow manually
<kintel>
Any concerns about that? e.g. we may have some keys accessible from inside the ci?
<kintel>
-> it's possible to harden it, if needed
<guso78>
suppose, no chance without a password...
<teepee>
are there secrets on github? circle-ci yes
<guso78>
suppose you have the openscad installer signer keys there... restricted access
<teepee>
that is on circle-ci
<kintel>
I don't think we even auto-download GitHub artifact, right?
<teepee>
correct, only circle-ci again, mostly due to github requiring authorization for reading public artifacts, which is annoying
<teepee>
although circle-ci seems to have introduced a similar stupid thing
<teepee>
I don't see any secrets setup on github, only a deploy key which I'm wondering what it is for
<teepee>
it claims to be used, but we don't deploy to github
<teepee>
maybe I just remove it and see if anything breaks ;-)
<kintel>
Where do you see that?
<teepee>
repo -> settings -> deploy key
<teepee>
secrets and variables is empty
<kintel>
Last used with the last week. No sure who is using that..
<teepee>
yep, not sure what for
<teepee>
let me remove it
<kintel>
I'll look into the hardening in any case (it would probably be limited to ssh public keys of specific people), but it sounds like enabling ssh for now might be ok, as long as it's limited to custom CI runs
<teepee>
yep, we don't use it for releases and input is public code only
<kintel>
I think, technically, this would allow us to fire up VS Code locally, and edit, build and run OpenSCAD code on the CI server until it times out (6h or so)
<teepee>
I guess so. I do have codespaces though which is quite similar :)
guso78 has quit [Quit: Client closed]
<kintel>
does codespaces support Mac or Windows yet?
<teepee>
I don't know, I've not really used it
<kintel>
Meh, "Regardless of your local operating system, your codespace will run in a Linux environment"
<kintel>
But yeah, ssh into CI is like DIY codespaces ;)
J2386764 has quit [Quit: Client closed]
J2386764 has joined #openscad
guso78 has joined #openscad
ur5us_ has quit [Ping timeout: 248 seconds]
<guso78>
kintel, did you even use texture uv coordinates from VBO buffers in a GLSL program ?
<kintel>
guso78 Not in a very long time : /
<guso78>
kintel, but at least you understood my question. that means i dont try to perform nonesense haha ...
<kintel>
I may have mentioned this before, but: I would strongly recommend prototyping your GL code in a minimal program, so at least you know that your code GL code is correct
<kintel>
-> it doesn't do textures, but I do have per-vertex colors as vertex attributes fed from a VBO
<kintel>
I also use VAOs in that example, but that's a thin layer on top of VBOs
<guso78>
i dont know for 100% how VBO's are working, i was able to achieve my success by templating, guessing, reading tutorials . maybe i need to learn from the start some time.
<guso78>
thank you for the link, i 'll try to get it working as-is 1st
<guso78>
kintel, would you enjoy that openscad(master) Preview(F5) can do textures when instructed ?
guso78 has quit [Quit: Client closed]
guso78 has joined #openscad
<guso78>
hmm, i cant get glfw3 in fedora core37
<kintel>
it's probably just glfw-devel in Fedora; I've only tested on Ubuntu
<kintel>
Not sure I understand where textures (and texture coordinates) would come from in OpenSCAD
<kintel>
..but it does sounds like a similar concept to the custom shader code from last year's GSoC
<kintel>
I do think, before adding new rendering feature, some significant refactoring is warranted though :) I'm still working my way through GL refactoring and I haven't added a single feature yet..
<guso78>
my idea is to specify one (or several) texture commands with a jpeg file are issues in the beginning of the SCAD file. then color("green", texture=1) could activate greeninsh 1st texture
guso78 has quit [Quit: Client closed]
guso78 has joined #openscad
<guso78>
Could not find a configuration file for package "glfw3" that is compatible
<guso78>
with requested version "".
<guso78>
hmm, its not exaclty PnP ...
<kintel>
Fedora is different I guess.
<kintel>
Perhaps just build it without glfw: cmake -DENABLE_GLFW=0
<guso78>
thank you for the hint.
<guso78>
i thought, GLFW is core component and is not optional
<guso78>
looks like you might receive some PR's on you offscreen ...
<guso78>
anyway, not today ....
<kintel>
meh, well it was worth trying. One day I'll see if I can get the CI running this on Fedora
kintel has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
ur5us_ has joined #openscad
epony has joined #openscad
foul_owl has quit [Ping timeout: 248 seconds]
kintel has joined #openscad
<kintel>
guso78 btw., which compiler do you use?
foul_owl has joined #openscad
J2386764 has quit [Quit: Client closed]
J2386764 has joined #openscad
<InPhase>
peeps[work]: Right. So that sounds like remaining thread correctness bugs.
<InPhase>
peeps[work]: Certainly worthy of an issue. The one I posted like that got attention really quickly.
<peeps[work]>
yeah i'll try to write one up this evening
<peeps[work]>
InPhase: what do you mean by thread correctness bug though?
<peeps[work]>
you think its in our implementation of manifold, and not manifold issue itself?
kintel has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<InPhase>
peeps[work]: It's probably in Manifold judging from the fact that it is new, and that it turns out the threading issue that I reported appears to have trickled upstream from us and got fixed in Manifold. But you can post it as our issue with the same mindset in mind. There's a collaborative attention going on.
<InPhase>
It's probably most proper as our issue until someone proves it's upstream with a little more attention.