califax has quit [Remote host closed the connection]
califax has joined #openscad
teepee_ has joined #openscad
teepee has quit [Ping timeout: 240 seconds]
teepee_ is now known as teepee
LordOfBikes has quit [Ping timeout: 240 seconds]
J2396 has joined #openscad
J23 has quit [Ping timeout: 245 seconds]
Guest10-David has joined #openscad
LordOfBikes has joined #openscad
Guest10-David has quit [Quit: Ping timeout (120 seconds)]
Guest10-David has joined #openscad
<Guest10-David>
Being a script based modeller, it seems that OpenSCAD would be ideally interoperable with a transformer AI tech such as GPT, including through ChatGPT. Is it known that interested parties are working on a plugin or API for GPT-4 for example?
Guest10-David has quit [Client Quit]
Guest10-David has joined #openscad
<teepee>
Guest10-David: not that I know of, although there was someone on the mailing list voicing some interest
<fact>
Not sure if here or the mailing list is the place for this question...
<fact>
I'm playing with geodesic spheres in OpenSCAD
<fact>
Is it somehow possible to modify a polygon so the edges don't touch? i.e. - Either reduce the size of the face or push the face further out.
<fact>
I figure if I do the modification as the faces are calculated the polyhedron won't "work" as they don't touch any more (adjacent faces)
<J23>
fact you constructing an object that can't exist in reality .. but you can give the walls a thickness .. so you can move them apart without having single faces in mid air
JakeSays has quit [Ping timeout: 248 seconds]
JakeSays has joined #openscad
fact has quit [Quit: Client closed]
L29Ah has quit [Ping timeout: 248 seconds]
Guest10-David has joined #openscad
Guest10-David has quit [Quit: Ping timeout (120 seconds)]
Guest10-David has joined #openscad
Guest10-David has quit [Quit: Ping timeout (120 seconds)]
fling has quit [Remote host closed the connection]
jonasbits has quit [Quit: No Ping reply in 180 seconds.]
jonasbits has joined #openscad
Guest8963 is now known as buZz
<guso78[m]>
IMO there IS No ideal geodesic sphere all of Them have certain irregularities
little_blossom has quit [Quit: little_blossom]
kintel has joined #openscad
little_blossom has joined #openscad
fling has joined #openscad
Guest2496 has joined #openscad
<Guest2496>
hi everyone
<Guest2496>
Can I ask a question?
<InPhase>
Certainly.
<Guest2496>
sphere(r=10, center=true);
<Guest2496>
This code line indicates WARNING
<Guest2496>
variable center not ...
<InPhase>
Yeah.
<InPhase>
It's centered by default, so there's no center parameter.
<InPhase>
The behavior of the primitives is to center round parts by default, and center square parts only if center=true. e.g., cylinder is radially centered always, but the height is only centered if center=true. So sphere is by this logic always centered.
Guest2496 has quit [Quit: Client closed]
<J23>
ok manifold crashes openSCAD more often …
<J23>
render() works but F6 crashes
snaked has joined #openscad
<guso78[m]>
Manifold IS Not involved with F5
teepee_ has joined #openscad
Guest20 has joined #openscad
Guest20 has quit [Client Quit]
teepee has quit [Ping timeout: 240 seconds]
teepee_ is now known as teepee
<J23>
https://imgur.com/a/pTE8cMs both parts render fine but the difference causing "manifold input not closed" and Surface_mesh ↦ Manifold conversion failed .. and crashes scad
<J23>
hm with fastCSG the preview only is over 1.5minutes
<J23>
doesn't look that complicated
castaway has joined #openscad
Guest10-David has joined #openscad
<J23>
8:49 render time well at least no errors with fastCSG
Guest10-David has quit [Quit: Ping timeout (120 seconds)]
<teepee>
hmm, and that is with the latest snapshot?
<J23>
2023.05.04
kintel has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<J23>
but this seems to be not replicable .. but it happens not just once - just got this with a new opened file, but not again after closing and opening
<J23>
ah ok no -- only when F6 .. preview always looks nice
<teepee>
so it's a script that always crashes? can you share that?
<teepee>
so crashes with f6 directly but not with f5 first?
<teepee>
that could be one of those cache issues feeding something invalid to manifold
kintel has joined #openscad
<kintel>
At some point, someone implemented an improved PNG exporter, which was independent of the rendered GUI size, but I cannot find it. Anyone remember that?
<teepee>
yep, let me see if I can find it, that was michael
rawgreaze has quit [Read error: Connection reset by peer]
rawgreaze has joined #openscad
dTal has quit [Ping timeout: 265 seconds]
dTal has joined #openscad
<J23>
teepee ok the low poly seems to be a result from a difference with a very big cube - so probably it is precision / grid related.
<teepee>
ah, right, there was some discussion about that, as manifold uses single precision floats
<kintel>
I gave Michael's animation export PR a spin. Unfortunately, it crashes inside the OpenGL driver : (
<kintel>
I fear we're making some assumptions about being able to share certain GL state between independent contexts..
<kintel>
The original PR crashes, as does the code rebased against master.. Only tested on macOS..
JakeSays_ has joined #openscad
castaway_ has joined #openscad
<InPhase>
J23: How large is the cube?
<J23>
the problem starting above 20 000
castaway has quit [*.net *.split]
little_blossom has quit [*.net *.split]
JakeSays has quit [*.net *.split]
<teepee>
:(
<J23>
So not sure why the crash happened but i changed put the difference as a last operation and now it works ( but it wasn't even when using only the difference with ! but maybe with ! the outside was still calculated )
<J23>
nope even if i remove the outside part it just crashes (close without warning)
<InPhase>
J23: That is indeed a massive cube. Although cubes that size scale often don't work well with CGAL or preview either.
<InPhase>
I've had a lot of issues with components of that scale going back very many years.
<J23>
in my lib the cube is 250 000 and i reduced it because i got problems with a bigger one .. it is only used in render in preview it is using a cube the size of the viewport to minimize view errors
<J23>
from the numbers scad can handle it didn't seem to be too big
<J23>
i sure agree that for printing 500 would probably enough for most cases
<InPhase>
I'm curious what math it is doing that it even has errors.
<InPhase>
The "difference" would not need to actually subtract these values, right?
L29Ah has joined #openscad
<J23>
you mean the crash case? now the difference is removing about 40 cylinders which are generated recursively
<InPhase>
No, I was thinking about the deformed image.
<J23>
there the cube is part of a difference module that substracting the cube from a children() // cutting the bottom e.g
JakeSays_ is now known as JakeSays
<J23>
InPhase as the cube is translated to cut the desired position a already (with the bigger cube) noticed very small changes which had to do with some grid iirc so maybe this causing some misalignement
snaked has quit [Quit: Leaving]
little_blossom has joined #openscad
Guest92 has joined #openscad
Guest92 has quit [Client Quit]
ali12341 has joined #openscad
ali1234 has quit [Remote host closed the connection]
<InPhase>
J23: Yeah. Just somewhere along the line this needs to have big value plus or minus small value, and I can't conceptualize where that has happened in this operation, because it seems to my mind like it shouldn't have to do that.
<InPhase>
It's possible it does have to in order to be generalized to all angles, and I'm just not seeing it. It's also possible it doesn't need to, and there's a operation rearrangement that could go into manifold to prevent it.