<joseph_>
InPhase: If you set the shader to default/original specifically using the menu, then the edges are still shown, right? That's what happens to me, indicating that it's always an issue with the default shader and not just when the program is first opened
snakedGT has joined #openscad
<InPhase>
joseph_: Okay, setting it to the "original" folder does in fact restore that flaky behavior again. Although that's also not really the original behavior. It looks like this is preview's "show edges" applied to render's colorless base colors.
<InPhase>
Show edges was in fact off, but this probably ties into how you made it work based off of that feature.
<InPhase>
And additionally, show edges isn't really supposed to apply to render. Although, you might rename that to a "show_edges" shader, and sort out a shader that complies with what render was doing before, or find a way to set the original behavior back if the feature is disabled. One of those.
<InPhase>
I notice the shader files are all labeled "Preview.*", which might be a strange choice for a final merge. These are the sorts of user experience things to start thinking about before wrap-up so that it turns into something a user will regard as smooth and sensible. :)
ghee has quit [Quit: EOF]
aiyion has quit [Remote host closed the connection]
aiyion has joined #openscad
drfff has joined #openscad
aiyion has quit [Ping timeout: 268 seconds]
aiyion has joined #openscad
LordOfBikes has quit [Ping timeout: 268 seconds]
juri_ has quit [Ping timeout: 245 seconds]
LordOfBikes has joined #openscad
TheAssass1n has quit [Remote host closed the connection]
fling has quit [Write error: Connection reset by peer]
teepee has quit [Read error: Connection reset by peer]
califax has quit [Remote host closed the connection]
aiyion has quit [Write error: Connection reset by peer]
TheAssassin has joined #openscad
califax has joined #openscad
aiyion has joined #openscad
fling has joined #openscad
teepee has joined #openscad
juri_ has joined #openscad
use-value has quit [Remote host closed the connection]
J1A849715 has joined #openscad
J1A8497 has quit [Ping timeout: 252 seconds]
TheAssassin has quit [Remote host closed the connection]
califax has quit [Remote host closed the connection]
TheAssassin has joined #openscad
califax has joined #openscad
califax has quit [Remote host closed the connection]
califax has joined #openscad
castaway has quit [Ping timeout: 240 seconds]
castaway has joined #openscad
juri_ has quit [Read error: Connection reset by peer]
juri_ has joined #openscad
juri_ has quit [Read error: Connection reset by peer]
juri_ has joined #openscad
fling_ has joined #openscad
teepee_ has joined #openscad
califax_ has joined #openscad
califax has quit [Ping timeout: 268 seconds]
califax_ is now known as califax
fling has quit [Quit: ZNC 1.8.2+deb2+b1 - https://znc.in]
teepee has quit [Quit: bye...]
teepee_ is now known as teepee
aiyion has quit [Remote host closed the connection]
aiyion has joined #openscad
fling_ is now known as fling
califax has quit [Remote host closed the connection]
califax has joined #openscad
use-value has joined #openscad
JordanBrown has joined #openscad
<JordanBrown>
Random tidbit: the openscad.exe I was building (Windows, msys2) was sometimes failing instantly when you clicked "new" from the welcome screen.
<JordanBrown>
It was fine immediately after I built it, but then later would go bad.
<JordanBrown>
Turns out that for some reason that I have forgotten, my script to run the tests copies opengl32.dll into the build directory.
<JordanBrown>
That's what causes it to die, though the tests themselves run fine.
<JordanBrown>
So, at least for my builds on my system, opengl32.dll is fatal to interactive OpenSCAD.
<JordanBrown>
(That's the Mesa opengl32.dll, from /mingw64/bin.)
JordanBrown1 has joined #openscad
JordanBrown has quit [Quit: Leaving]
JordanBrown1 is now known as JordanBrown
<JordanBrown>
Hexchat was dying (maybe when the screen saver kicked in?), so let's try the chat that's built into Thunderbird...
<joseph_>
teepee: Is there anything else we need to discuss before I submit my part of the midterm evaluation?
<teepee>
joseph_: I don't have anything specific for the evaluation, it would be nice to have a bit more discussion on the further steps for the 2nd part
<teepee>
e.g. how to extend the GUI / maybe check what options there are for extra parameters that could be passed to the shader / ...
<joseph_>
teepee: Ok, I will submit my form in a few minutes. I was thinking it would be better to address bugs first and then add new shader attributes after, but let me know if you have a different thought. And in the second half I will make more of an effort for synchronous interactive discussions here. InPhase already suggested the general hours he is more likely to be online, is this something you can predict for yourself?
<teepee>
I've not seen the issue InPhase mentioned, but I think I tested with one commit before. but yes, looking at bugfixing seems like a good first step
<teepee>
he also was pretty spot on with the times I'm on. I am in CEST = UTC+2, but usually around at least till midnight
<teepee>
I used to be on even later than that, but lately I'm in a project which has a daily call at 9 a.m. so at least I'm trying (and mostly failing) to be in bed at 1 a.m. :-)
<InPhase>
joseph_: Be sure not to submit your form late.
<InPhase>
joseph_: They're on UTC time I think, or whatever was specified. Some people submit late and then get dropped and don't get paid anymore. Happens every year.
lastrodamo has quit [Quit: Leaving]
<InPhase>
teepee: Maybe "trying and failing to be in bed at 1am" can go on the GSoC t-shirts this year.
<joseph_>
teepee: Sounds good. To your point about additional shader parameters, looking at #3860 there was a bit of discussion about ambient occlusion and multiple passes. I'd need to do some reading on this first because we didn't do a deep dive into AO in my university class. Using it for depth/proximity may be similar to something I tried a few months ago in Blender but of course that abstracted away many relevant parts
teepee has quit [Ping timeout: 268 seconds]
teepee has joined #openscad
aiyion1 has quit [Remote host closed the connection]
aiyion1 has joined #openscad
<joseph_>
InPhase: Thanks for the warning. Fortunately the dashboard converted the deadline to localtime for me. And I just submitted it. But I can imagine people still miss the deadline if they never visit the dashboard until they want to submit
<teepee>
yep, traditionally it's good advice, especially for GSoC to submit latest one day before the deadline
<teepee>
there's always people missing those due to random issues like network outages and such
<JordanBrown>
Very nearly impossible to be related to my work.
<JordanBrown>
But 10 greens from CI. Yee hah. Anything else you'd like to see on the PR? Any opinion on whether I should strip out the "raw" stuff, leave it under #if, or do something more elaborate with it? Is it helpful for me to strip out the "junk" commits, or does that happen anyway when you merge the PR?
<teepee>
hmm, that's newer then what we are using anywhere else
<JordanBrown>
It's what I got when I updated my MSYS2 environment...
<teepee>
and as the CI green shows, it's not exactly one of the most trusted test cases. trying to toss bad data at CGAL can be tricky for testing
<teepee>
well, either that, or it's a new thing with 5.5
<JordanBrown>
Like I said, I'm not worried about it for *my* work. But any failing test case is bad.
<teepee>
either way, I agree that it's extremely unlikely it's related to the text changes
<teepee>
maybe I find some time on weekend to update to cgal-5.5, if they did not drop too much backward compatibility again, it should be relatively easy
<JordanBrown>
Well, the good news there is that it built OK for me...
<teepee>
the worry is for the older builds, the new stuff should be fine
<teepee>
there's already 2 patches to roll back to be compatible with ubuntu 18.04
<JordanBrown>
ah
GNUmoon2 has joined #openscad
* teepee
goes checking release notes
<teepee>
hmm, strange. I do remember reading something about boost compatibility but can't find it anymore
<teepee>
¯\_(ツ)_/¯
<teepee>
oof, they claim g++ 10 required which would even rule out 20.04 LTS
<teepee>
hmm, and 5.4.2 already does too, and boost 1.66 which not in 18.04 LTS
<teepee>
we'll see I guess
snakedGT has quit [Remote host closed the connection]
snakedGT has joined #openscad
<teepee>
JordanBrown: coming back to the other questions... there's no selective squashing support on github I'm aware of, it's only possible to do full merge keeping all commits or complete squash to a single commit
<teepee>
so cleaning up would need to be done via force-push to your branch - which is generally fine for feature branches, it's just a absolute no-go for master or long living branches multiple people are working on
<teepee>
as for the "raw" info, we need to find a way to make clear it's not part of the API, I guess it's useful enough to have a way to access that info, but we have enough backward compatibility problems without officially exposing data structures from external libraries ;-)
<teepee>
even if freetype is probably pretty stable
snakedGT has quit [Remote host closed the connection]