03:55 <joseph_> teepee InPhase: Today I worked on adding a menu item for shader switching, but it's not done yet. I've also thought about options for extending the work period. I think bringing the total to either 14 or 16 weeks would be a good idea. There are pros and cons to each. 16 weeks gives more of a buffer for future delays, but it might be more than I need. Either option would end after my fall semester starts

04:12 <joseph_> I don't know if there is any downside to extending the work period longer than it might be necessary. I'm trying to estimate broadly how much work remains. It seems like I just finished the most intensive part, which is locating and learning about the relevant parts of the renderer architecture for my task. The remaining development will likely focus on fixing rendering bugs, testing, all the UI/IO, and then supporting additional

04:12 <joseph_> uniforms. Not to say that these won't take time and effort, but they are more conducive to the traditional approach of small-scope and frequent commits/PRs. Also, the familiarity I've gained thus far means future work will likely proceed much faster

04:14 <joseph_> If we use the initially defined milestones from my proposal as a guide, then I am at least a little over two weeks behind where I wanted to be.

07:34 <teepee> joseph_: it's just an option that seems to be possible now. we can just keep the normal timeline if you think that works

11:56 <gbruno> [github] johannespfister opened issue #4301 (Feature Request: Make OpenSCAD language more normal) https://github.com/openscad/openscad/issues/4301

12:20 <J1A843649> what is that?

12:21 <InPhase> I find myself needing to chuckle before I click on issue #4301 to see what it says. :)

12:22 <J1A843649> "normal" is a word nobody should use Ü

12:36 <teepee> :)

12:37 <teepee> well, we are not getting pointers, that's for sure I would say

12:43 <Friithian> InPhase: so I printed those nails in PLA, ABS, and PETG. They all failed the go more than a 2cm into a block of wood :P

12:46 <J1A843649> Friithian try PEEK https://upload.wikimedia.org/wikipedia/commons/3/3c/Highperformance_thermoplastics.svg

12:48 <J1A843649> PC could give acceptable results maybe CF-PC   .. or just use softer wood

12:48 <Friithian> oh hey I can do PC on these printers

12:49 <J1A843649> i love printing PC .. just bit expensive and not needed for most cases

12:50 <Friithian> still cheaper than natural PVA

12:51 <J1A843649> oh didn't know PVA was that expensive

12:51 <Friithian> https://www.matterhackers.com/store/l/natural-pro-series-breakaway-support-material/sk/ML3K9S81

12:51 <J1A843649> .oO for that price i would expect at least water resistance Ü

12:52 <Friithian> it's water soluable

12:53 <Friithian> you use it for support

12:53 <J1A843649> i know was joking

12:54 <J1A843649> but  the price for PC is higher  .. (spools are smaller)

12:57 <J1A843649> I know that some use PVA only for the support interface not the full support

12:58 <J1A843649> but depends if you can get the support out ..  there was someone using a Pen on the printer to just paint the interface so it will not combine with the next layer

13:25 <InPhase> Friithian: Yep, sounds about right on the nails. :)

13:26 <InPhase> Friithian: Or should I say, you hit that nail on the smooshed head.

15:10 <Friithian> InPhase: lol it didn't even smoosh it all cracked and split

15:29 <J1A843649> maybe vertical printing has improved properties

15:36 <Friithian> I could try that

16:19 <gbruno> [github] t-paul edited issue #4301 (Make OpenSCAD language more normal) https://github.com/openscad/openscad/issues/4301

16:24 <joseph_> teepee: I think it depends partly on what you and InPhase think of my current method for applying a shader to the F6 render. If you find a significant flaw in my solution (I'd especially like to hear what you think about converting all polyhedrons to polysets), in my mind that would merit a longer extension of the deadline. Also, I need to think about what work I need to do this week ahead of the midterm evaluation. So far on my

16:24 <joseph_> list is to retroactively write my dev log and complete a functioning menu item for shader switching

16:49 <teepee> joseph_: can you give some specific pointers for that conversion? when would that happen? as separate step before display?

16:50 <teepee> if it's such a big change in plan that it would be the only reason to change the timeline, then maybe it's too big to be done right now

16:55 <Friithian> oh fuck so apparently the CNC shopbot we have can take STLs in and carve out the STL

16:55 <joseph_> teepee: I've already implemented the polyset conversion on this line: https://github.com/jbinvnt/openscad/commit/ee2fdf68d481ff669b396803506398ac353a911d#diff-da2b2e3c1190b425f1f5cd028dd83e81cb15334c4ed9d40db6b4a304ea4dd049R71. It seems to work but I wanted to hear if you had concerns about this type of approach

17:03 <teepee> I'm not sure about all the implications, it might cause some more back and forth conversion which could impact both performance and risk more issues due to the number precision issues

17:21 <InPhase> joseph_: I was working pretty late last night and didn't get a chance to review your code yet, so I don't have a judgment on the methodology available yet. But to guide our eyes to the critical questions perhaps you can give us a pro/con analysis of what you think the issues are with the approach

17:32 <gbruno> [github] Jimw338 opened issue #4302 (Request/Question: Contextual menu showing "element tree" for model right-click. Adding rendering time information. Where in code?) https://github.com/openscad/openscad/issues/4302

19:04 <joseph_> InPhase: The benefit is that it seems to my eye there is no existing support in the code for rendering polyhedrons with VBOs. Either way, it was less work to just convert them to a polyset which I already can render using the modern method. There is now just a single type of surface, and one less place to where future changes are required. As for downsides, I don't know of any yet. But I wonder why the polyhedrons were drawn

19:04 <joseph_> directly in the past unless there was a good reason for it. Maybe peepsalot or someone knows

19:16 <peeps> converting to polyset loses information about which faces were cut, for one thing. those are normally colored different in render

19:25 <J1A84> i think fastCSG is doing that

19:29 <teepee> yeah, as that's yet another data structure used.

19:30 <teepee> if that's really just done for the display on screen purpose it's probably fine as it's the final step anyway

19:31 <teepee> at first glance I was not sure if that happens in the middle of processing too which would potentially impact also caching and such

20:08 <teepee> joseph_: I've poked at this a bit more and as this conversion is local to just the CGALRenderer it looks fine, I think we can certainly keep it now

21:53 <gbruno> [github] jpswensen opened issue #4303 (Proposal for how to center imported STL files) https://github.com/openscad/openscad/issues/4303

21:53 <gbruno> [github] jpswensen edited issue #4303 (Proposal for how to center imported STL files) https://github.com/openscad/openscad/issues/4303

21:55 <gbruno> [github] jpswensen edited issue #4303 (Proposal for how to center imported STL files) https://github.com/openscad/openscad/issues/4303

22:12 <J1A84> hm just checked and  the imported stl are centered - probably depends how they were saved

22:14 <J1A84> and a bounding box can be misleading about the center if it is an irregular object or just odd number of edges

22:43 <InPhase> The mean coordinate of the points is also very rarely what is wanted. That's not even a center of mass.

22:43 <peepsalot> stl specify an absolute location and import does not change it

22:44 <gbruno> [github] jordanbrown0 opened issue #4304 (text scaled wrong (resolution = 100 should be 72)) https://github.com/openscad/openscad/issues/4304