00:35 <dTal> and of course eventually OpenSCAD can use that shader architecture to support full color management with ICC profiles

00:39 <dTal> (don't worry, I'm kidding - color management on Linux is a wild goose chase)

13:09 <AndrewStone[m]> Is "render()" kind of like "independent"? That is, nothing below this will interact with any siblings so the code can go ahead and evaluate these objects independently of anything else in the scad file?

13:13 <teepee> render() means: force mesh calculation at this point in the geometry tree

14:09 <InPhase> AndrewStone[m]: Everything is able to be independently evaluated like that, regardless of render.

14:10 <InPhase> AndrewStone[m]: But everything, render or not, can then undergo computational geometry combinations farther up the tree.

14:10 <AndrewStone[m]> When would you want to use render and when would you definitely NOT use it?

14:12 <AndrewStone[m]> I'm trying to understand the ramifications of "forcing mesh calculation"...

14:13 <InPhase> AndrewStone[m]: Most of the cases where I've used it have been to speed up display navigation. Some designs are really laggy when you're spinning around the view and looking at things, but doing a render puts that delay into the preview calculation, which can then cache the render result, meaning after paying that price once you can get fast previews and fast navigation.

14:14 <InPhase> There are a few cases also where it can clear up preview artifact issues.

14:15 <InPhase> As render always happens when you are rendering, adding a render does not impact the rendering of objects and thus does not impact output. So it is only to impact what happens with a preview.

14:15 <InPhase> This may be altered in the future with the data = render() PR, which is designed to give variable access to the render results.

15:31 <J2254> showing transparent objects also look different with render as their geometry is not grouped but unioned

15:34 <J2254> https://pasteboard.co/oVIrozXb5QLF.png

15:35 <J2254> iirc it also can help when running into tree limitations when having too many objects

16:25 <InPhase> J2254: Interesting difference. Hadn't thought of that one.

16:30 <J2254> inPhase also useful in intersections as you have no internal edges when translucent

16:43 <AndrewStone[m]> J2254: so the left one is made calling render()?

16:44 <J2254> yes

17:04 <J2254> AndrewStone[m] also you may have seen the z-fighting if two faces are at the same place - this is cleared with render() too

17:04 <J2254> it also can speed up animations

17:06 <J2254> if the part behind render() doesn't change else it will take longer till all frames are chached

17:08 <AndrewStone[m]> I can see what you all are saying about speeding up the viewport's frame rate. I made a nasty fractal scad to torture the system and was getting maybe 2 FPS panning things around. After adding render() (which took 5GB and all the time since my last post to complete) the viewport is now panning at a good FPS.

17:11 <J2254> just don't change anything behind the render()  Ü

17:12 <J2254> same effect is to export a geometry and import it  ( as this is then rendered too )

17:14 <AndrewStone[m]> and in theory, we could speed things up by launching everything below render() as its own thread when doing the initial volume->mesh conversion, right? That is, an object outside of the scope doesn't effect the execution of render() (even if it overlaps it) because that union/difference/intersection is done later?

17:15 <AndrewStone[m]> * things up (assuming the model has more than 1 render() with changed children) by launching

17:17 <AndrewStone[m]> I just noticed I lost a color() inside a render() but could apply it outside? Is this a bug or expected behavior of the reduction to mesh?

17:17 <J2254> expected as geometry has no color

17:18 <J2254> (at least in SCAD)

17:19 <J2254> you could make a cube with different colors - but the mesh only store the points without vertex color

17:20 <J2254> still if one time this would allow to export colors into 3mf files  ( stl files can't store color either)

17:23 <AndrewStone[m]> makes sense, thanks for your help!

17:28 <gbruno> [github] MichaelPFrey pushed 1 modifications (this is implemented) https://github.com/openscad/openscad/commit/31b29931690ead296b72e8ae0441d24b6d25c5e7

18:07 <retrosenator> can someone help me with subtractive minkowski?

18:08 <dTal> confucius say, subtracting the positive is the same as adding the negative

18:52 <retrosenator> how?!

18:52 <retrosenator> i want to use minkowski to cut away using a sphere

18:52 <retrosenator> instead of add

18:52 <retrosenator> can I use negative radius sphere?

19:58 <gbruno> [github] t-paul pushed 2 modifications (Merge pull request #4208 from MichaelPFrey/mfr-2022-04-08-high Only show hyperlinkIndicator as active when a modifier key is pressed and add tooltip.) https://github.com/openscad/openscad/commit/e62afcf5d524638aaf5014fbd32ff8ddeac9e29d

20:57 <InPhase> dTal: Except that you can do one and not the other. :)

20:59 <InPhase> (For which I should clarify neither are supported, but only the one would be well defined for properly manifold geometries.)

21:01 <dTal> well you can invert a shape - that is, turn solid to empty and empty to solid - and minkwoski that

21:01 <dTal> it's not exactly clear what retrosenator was aiming to acheive

21:01 <InPhase> Probably the 3D equivalent of the 2D offset(-2)

21:02 <dTal> that makes sense

21:02 <InPhase> What we really need is a 3D offset. It would probably be much faster than the general minkowski.

21:03 <InPhase> The abstract sphere is a special case with useful optimization potential I think.

21:05 <Scopeuk> I suspect but can't prove that a large chunk of the use of minowski is to round or chamfer 90 deg edges a more limited function "perfect world" probably operating subtractivly i.e. knocking the corners off, if implementable to be light could eat up a lot of cases

21:12 <InPhase> Yep.

21:13 <InPhase> I'd say the vast majority of it is either rounding corners and edges, or chamfering.

21:14 <InPhase> I basically targetted smooth-prim at hacking away the easy cases of this usage. https://github.com/rcolyer/smooth-prim But there remain the non-easy cases.

21:27 <Scopeuk> Yeh I tend to approach that sort of task with hull these days, for some reason I tend to go for my own solution before thinking about libraries

23:03 <InPhase> Scopeuk: If smooth-prim were written by someone else, given my personal character traits I would probably simply use it as a reference guide. But that's mostly just in where my core interests rest. Given that I've written it, my usages of it are split somewhat evenly between use<>, copy/paste, and reference guide for a customization.

23:05 <InPhase> That sort of derives from the fact that I wrote it because I was interested in that problem. But now I'm not so interested in those problems because I experienced the solution to each one. :)

23:12 <joseph_> InPhase teepee: I cloned/built the repo and started investigating #3706. I added a comment on the GH issue, but I don't have a PR ready just yet. Also I'm an IRC noob, can you please explain how channel logging works? So far I've just been leaving my client open all the time

23:16 <teepee> joseph_: there's a link in the channel topic

23:17 <teepee> as the deadline for the proposal is not far way, it might be better to focus first on the proposal and use the review time period for the code investigation

23:22 <joseph_> teepee: Thank you. I will get started on the proposal tonight. Is there any template I should follow beyond what Google suggests? I can write it as a markdown file in a separate GitHub repository if that will be easy for you to review

23:24 <teepee> sounds ok to me, you can check the previous ones for general content like useful structure, but format is not so critical as long as it can be shared and discussed

23:25 <teepee> hmm, that said, I'm not sure the old ones are still public, I think google keeps only the abstract :(

23:27 <teepee> yeah, only abstract, but the main structure should be mentioned on our gsoc website

23:29 <teepee> yep - https://opencax.github.io/gsoc_guidelines.html

23:30 <teepee> when it says background info, that means technical/programming background, not personal identifying information

23:46 <teepee> and I'm off to bed, don't worry too much about formatting, there's 3 important things: 1) outline and detail the work that will be done 2) lets keep the discussion going 3) don't miss the deadline, you can upload updates, don't wait till last moment

23:47 <teepee> pretty much every year there's people who failed to join due to some technical problem in the last hour, and those deadlines are handled by the google dashboard, so there's nothing on our side that can be done

23:57 <InPhase> joseph_: There are advantages to leaving your client open in that all the decent ones will highlight lines that have your name on them, and you can also potentially receive private messages. (Although most of the GSoC work discussion ends up in-channel most years so that there is opportunity for broad feedback and input.) So you can certainly use the posted logs just fine, especially if staying

23:57 <InPhase> connected ever becomes an inconvenience. But I find it pretty convenient to be connected all the time. I've probably been connected to some sort of IRC networkfor the majority of the last 28 years.