<Andy-pants>
What's the best way to create a union of a cylinder and a sphere of equal diameter centered on the end of the sphere? The cylinder is slightly wider when both primitives are provided the same diameter.
<Andy-pants>
Is that difference a known ratio that the cylinder can be scaled by?
LordOfBikes has quit [Ping timeout: 246 seconds]
<Andy-pants>
Or is this all in my head? XD
<linext_>
so a cylinder with a spherical hole in the middle?
<Andy-pants>
Imagine a cylinder with a spherical end
<linext_>
ok
<linext_>
that's it?
<Andy-pants>
Though, to answer my question. Yep, it was all in my head. The problem was two-fold:
<Andy-pants>
1) In preview mode, the sphere rendered with a smaller radius than the cylinder. But, when rendered with a higher number of faces, they rendered the same diameter
<Andy-pants>
2) The bottom of the cylinder was narrower than the top (where the sphere was). So there was geometry of the sphere clipping through the tapered cylinder. Cutting the sphere in half with a difference of another cylinder did the trick.
<linext_>
you can increase $fn to make it more round
<linext_>
but yes, the sphere appears to be slightly thicker in circumference than the cylinder
<Andy-pants>
Yep! And that's what I did.
<linext_>
if you use hull, it gets rid of the edge
<Andy-pants>
I use a ternary operator to determine if it's in preview and if so, user a lower fragment count, otherwise I crank it up. `$fn = $preview ? 20 : 100;`
<Andy-pants>
Also, using a hull is a brilliant idea, and considerable easier to implement and understand. Thank you for the suggestion!
<linext_>
oh yea, is that $preview true only if f5 preview render is used?
<Andy-pants>
Yep!
<linext_>
even on my top of the line 7950x amd processor, rendering can take a while
<linext_>
it's twice as fast as my 2020 computer running an i9900k
<Andy-pants>
I assume better single thread performance on the intel?
<linext_>
no, the intel from 2020 has about 50% single-threaded performance as the amd from 2022/2023
<Andy-pants>
Hrmm. Interesting
<linext_>
it's not really intel vs. amd though
<linext_>
processors have doubled in single threaded performance in general in the last 3 years
<linext_>
intel top of the line are slightly faster, but with fewer performance cores
<linext_>
also, i made this website which can run openscad without downloading it
fling has quit [Remote host closed the connection]
fling has joined #openscad
guso78 has joined #openscad
<JordanBrown[m]>
Andy-pants: That sphere problem is interesting. I don't know exactly how OpenSCAD generates spheres, but the issue is present for any sphere with an even number of lines of latitude. I think that the (theoretical) equator is the right size, but if there are an even number of lines of latitude then the sphere doesn't have an equator.
<JordanBrown[m]>
It looks like it's OK for $fn=5, 6, 9, 10, 13, 14, et cetera, but I don't know why it's that pattern.
<JordanBrown[m]>
If so, that suggests that the "best" values for $fn are 4n+2.
<JordanBrown[m]>
Or just set it big enough that you don't care about the tiny error.
<JordanBrown[m]>
Spheres based on icosahedra are a lot nicer. I wonder whether it would be possible to come up with a scheme that would let us switch over to them with minimal compatibility problems.
<guso78>
JordanBrown[m], i believe you could start with an tetraeder and then perform an hierarchical "divide and conquer" approach, until $fn, $fa and $fs conditions are met. believe this will create more nice spheres
<guso78>
the algorithm is each" calc the extra point, which has the correct radius and replace the exising triangle with 4 new ones
<JordanBrown[m]>
That's basically the same as the icosahedron approach.
<JordanBrown[m]>
You can definitely make very nice spheres, but since they aren't quite the *same* as our current spheres there may be issues.
<guso78>
suppose the only issue is that the ctest images created are different but all humans will consider them nicer
<JordanBrown[m]>
For instance, somebody might have looked at this particular problem and "fixed" it by scaling the sphere up just a little bit. They would then be broken with a new sphere design.
<guso78>
i had put little effort on them when i was in openscad community 3-4 back , but was not desired at that time.
<JordanBrown[m]>
Or people might have built in assumptions around the fact that our current sphere never have a vertex at the north and south poles.
<guso78>
JordanBrown[m], this is correct, but if an user "fixed" it. i t was rather "messed it"
<JordanBrown[m]>
But maybe we could have a parameter to sphere or a $ variable that controls the sphere behavior and enables these alternative schemes.
<guso78>
its as easy as adding a parameter "ico" to spheres which is off by default
<JordanBrown[m]>
Right. Or something. A "mode" parameter, perhaps, to allow for other schemes.
<guso78>
actually i would love to see ico spheres for years, but i have many other construction yards already. i am confident, somebody else eagers to do that.
<JordanBrown[m]>
And yes, "fixing" it by scaling would be wrong, but unfortunately sometimes you need to maintain bug compatibility.
<JordanBrown[m]>
I believe there are several libraries that do them, so except for the slight inconvenience they're available.
<guso78>
i believe an hierarchial algorithm in openscad to get the face indexes correct for the ico sphere can be quite tricky ....
<peeps[zen]>
subdivided octahedron are the nicest IMO, since they can have seams that line up with all cardinal directions (rounded boxes etc)
<guso78>
peeps[zen], i believe i can make another match between github name and IRC name
<peeps[zen]>
JordanBrown[m]: the code will also do sphere from subdivided icosahedron, which is fine if not trying to create seamless transition to right-angle-only faces
<guso78>
peeps[zen], is the [zen] the origin you are coming from, where [m] is matrix and [alot] is something else ?
<peeps[zen]>
guso78: peeps is short for peepsalot (originally short for "Sir Peepsalot", kinda like Sir Lancelot), but the zen is just an variation on nick for my irc client to try when the main is taken (this desktop has an AMD RyZEN CPU).
<guso78>
Haha great. BTW I like the fairytale a lot !!!
<peeps[zen]>
so if for example a connection with irc server drops, then a little later the client is able to reconnect again. often the nick which was just logged in still counts as being used, so i usually put an alternate nick on each computer that I use IRC on
peeps[zen] is now known as peepsalot
<peepsalot>
i don't really use matrix, though i dabbled with it briefly. just HexChat and plain IRC
<guso78>
is HexChat a Website/AndroidApp/Company/Tool/WindowsProgram/Whatever ???
<peepsalot>
anyways its a silly name i used in a game once many years ago, and then I kinda stuck to using it for way too long for many of my "informal" online settings (particularly IRC)
<teepee>
quote: "The BRL-CAD source code repository is the oldest known public version-controlled codebase in the world that's still under active development, dating back to 1983-12-16 00:10:31 UTC."
<teepee>
:)
<J2368>
new to me .. but i think i have seen one of the images from their website .. however raytracing is nice
<teepee>
yeah, it's a bit unusual but pretty powerful covering lots of cases
<teepee>
plus they host us for GSoC for about 10 years
<J2368>
"used by military" means they have money Ü
<teepee>
we even tried sharing DXF code but that did not quite reach a releasable state
<J2368>
The coolest place in the universe. —— there are too many "coolest" places in the universe .. 0K
teepee_ has joined #openscad
teepee has quit [Ping timeout: 255 seconds]
teepee_ is now known as teepee
gimzmoe has joined #openscad
<gimzmoe>
is there a way to use values internal to a function, specifically I'd like to use the radius dimensions from gear functions as translation inputs for assemblies of gears
J2368 has quit [Quit: Client closed]
J2368 has joined #openscad
BZK[m] has quit [Ping timeout: 256 seconds]
evils[m] has quit [Ping timeout: 260 seconds]
Cadair has quit [Ping timeout: 265 seconds]
JordanBrown[m] has quit [Ping timeout: 265 seconds]
boriyakasumo[m] has quit [Ping timeout: 265 seconds]
xloem[m] has quit [Ping timeout: 252 seconds]
TED[m] has quit [Ping timeout: 252 seconds]
Notkea has quit [Ping timeout: 260 seconds]
LinuxHackerman has quit [Ping timeout: 260 seconds]
one-star-chef has quit [Ping timeout: 248 seconds]
mikolajw has quit [Ping timeout: 264 seconds]
aliervo[m] has quit [Ping timeout: 260 seconds]
Number3[m] has quit [Ping timeout: 260 seconds]
nbr0wn[m] has quit [Ping timeout: 264 seconds]
aiyion1 has quit [Ping timeout: 255 seconds]
aiyion1 has joined #openscad
boriyakasumo[m] has joined #openscad
JordanBrown[m] has joined #openscad
aliervo[m] has joined #openscad
Number3[m] has joined #openscad
TED[m] has joined #openscad
nbr0wn[m] has joined #openscad
Cadair has joined #openscad
fling has quit [Ping timeout: 255 seconds]
fling has joined #openscad
Notkea has joined #openscad
BZK[m] has joined #openscad
mikolajw has joined #openscad
evils[m] has joined #openscad
xloem[m] has joined #openscad
J2368 has quit [Quit: Client closed]
J2368 has joined #openscad
LinuxHackerman has joined #openscad
one-star-chef has joined #openscad
J2368 has quit [Quit: Client closed]
J2368 has joined #openscad
gknux has quit [*.net *.split]
SenFache has quit [*.net *.split]
buZz has quit [*.net *.split]
Virindi has quit [*.net *.split]
InPhase has quit [*.net *.split]
Ekho has quit [*.net *.split]
vsellier has quit [*.net *.split]
abff has quit [*.net *.split]
mlaga97 has quit [*.net *.split]
buZz has joined #openscad
SenFache has joined #openscad
Virindi has joined #openscad
Ekho has joined #openscad
InPhase has joined #openscad
abff has joined #openscad
mlaga97 has joined #openscad
vsellier has joined #openscad
gknux has joined #openscad
SenFache has quit [Remote host closed the connection]
<InPhase>
lf94: Yes, micro-papers are definitely needed, along with a major revision in the culture of what counts as meritorious publication. The fields have drifted far from optimal in this process, and it is being broadly recognized that we need major revisions to this process. Many variations are being proposed and tried, and it will take time to settle on the new accepted formats and procedures.
<gimzmoe>
lf94: I was thinking about a similar concept but using jupyter notebooks to publish as html to IPFS
<InPhase>
lf94: I routinely produce documents and small reports that have extremely valuable information, which ends up distributed almost entirely informally because there is no established process for recognized formal dissemination. Instead everyone wants you to build up major piles of results into big papers that will go into more reputable journals and get higher concentrations of citation counts.
<lf94>
Ah
<InPhase>
lf94: I'm sitting on tons of information that the rest of the world should know. Some that the world will never see because attempts to make a big paper fell apart, and some that I'm still actively working on making into big papers.
<InPhase>
And some that just doesn't fit into the format of an accepted information, so it gets passed around only through contact networks.
<gimzmoe>
the author wants to use arXive, but it sounds like https://ipfs.tech/ would be a better option and a bit of a killer app
<InPhase>
lf94: And it's not for lack of trying. I had one article of pretty significant value rejected for not having enough different approaches in it. It was a solid idea for a method, demonstrated cleanly, and proposing for others to make use of the new method, submitted for publication while closing down a project. And then it got rejected, and I ran out of time to keep reformatting it to different
<InPhase>
journals and submitting and hoping for one to bite. So the knowledge of this useful method just sits there in my files and in my head, lost to society. And this happens a lot.
<lf94>
that sucks
<InPhase>
The modern approaches to filtration started only in the 1970s, so most science we are accustomed to was done productively without this. And it continued to change with market dynamics in recent decades, and now basically doesn't work well.
Andy-pants has joined #openscad
Andy-pants has quit [Client Quit]
Andy-pants has joined #openscad
<Andy-pants>
Does anyone know of any guides for optimizing code for improving rendering time?
<lf94>
Good question
<lf94>
I'd say avoid difference() blocks
<lf94>
(so by extension, intersection also)
<lf94>
union is very fast iirc
<Andy-pants>
oooh, that's interesting
<lf94>
Try to "sketch" using polygon if you can
<lf94>
It'd help to see what kind of code you're dealing with too
<lf94>
Very possible I'm not thinking of something
<Andy-pants>
I'm going to clean things up for understandability first. Then I'll get it pushed up to gitlab. It's a mess right now. 😅
<J2368>
Andy-Pants do as much as possible in 2D
<J2368>
like add a circle and square ↦ rotate_extrude not using a cylinder and sphere
<Andy-pants>
Hrmm. I'll consider that.
<J2368>
you already using fast-CSG?
<J2368>
always ensure overlap as coplanar faces cost big render time
Andy-pants has quit [Ping timeout: 248 seconds]
Andy-pants has joined #openscad
epony has quit [Read error: Connection reset by peer]
<InPhase>
Andy-Pants: For the things you've been discussing for the past day or two, major leaps of optimization can come from switching to this approach: https://github.com/rcolyer/closepoints
<InPhase>
Andy-Pants: You'll get near instantaneous render times of these sorts of items.
<InPhase>
You can still get non-instantaneous render times doing subsequent CSG combinations of the results of ClosePoints with other rendered objects, but these sorts of combinations are only really a function of the total facet count.
<InPhase>
Andy-Pants: That demo_roller_coaster.scad file, for example, renders in 0.26s, and has zero artifacts or overlap issues, because every point along the path is exactly where it's supposed to be, with no messy overlap problems.
epony has joined #openscad
<Andy-pants>
@InPhase I suspect that overlaps are killing me. I'm going to poke at that a bit.
peeps[work] has joined #openscad
<lf94>
> @
<lf94>
On IRC it's custom to use <name>: B)
<lf94>
InPhase: bleep boop
Andy-pants has quit [Ping timeout: 248 seconds]
guso78 has joined #openscad
TheAssassin has quit [Remote host closed the connection]
<guso78>
openscad-manifold took notice of the small cube, but not of the self intersection.
<guso78>
it appears, manifold is not what i was waiting for.
<guso78>
now studying paper from Julien M. Smith
<InPhase>
Surely the manifold library has utilities for making things manifold. It's in the name. And if not, it surely will eventually, given the name. It's an early development.
milza has quit [Quit: milza]
ur5us has joined #openscad
<lf94>
I guess I couldnt get paid to work on sdf stuff for openscad eh
<lf94>
ripperoni
<InPhase>
Well you could if you found someone willing to pay for it. But good luck with that!
guso78 has quit [Ping timeout: 260 seconds]
guso78 has joined #openscad
<teepee>
guso78: yeah, I'm not sure it's supposed to make random input manifold, the guaranty might be for results of manifolds
<teepee>
what paper is that? some mesh fixing?
<guso78>
its the paper where manifold was developped from. let me check for you
<guso78>
will read next and will adapt my algorithm with the "new learnings"
<guso78>
teepee, the result of my offset is mathematically correct input. in each corner adjacent faces build a closed loop. only issue is that there are volumes with <1 allocation and volumes with >1 allocation. this is where i need a solution to fix.
<teepee>
hmm, reading >100 pages... next century maybe...
<guso78>
hmm, long time to spend until next century, not sure if you can survive that
<guso78>
better reading it earlier. going to print it out with the company printer tomorrow :)
<teepee>
true, retirement then :)
<guso78>
i am 44 and i doubt you are younger haha
Andy-pants has joined #openscad
<teepee>
yep, a bit further down on the way to half a century
Andy-pants has quit [Ping timeout: 260 seconds]
<guso78>
just a stupid question ? is there a file format, which can store an 3d video (in contrast to an 3d state = STL) where actors are Points, Lines, Arrows maybe ?
<guso78>
Faces ...
<guso78>
need that to trick and aid my imagination
<guso78>
of course an player for that file is also useful
<guso78>
hmm, i read the keyword animation, but probably i need to first understand, what GLTF is about ....
<teepee>
it packages both mesh and assets as far as I understand, so it can transfer full scenes
<teepee>
I don't know much about the details though
<guso78>
why dont't assemble a new file format which embeds several STL's in one file. A Player for the file will choose the viewing angle while it plays
<guso78>
need to dig more in detail for GLTF though ...
<guso78>
The user will choose the viewing angle of course ....
ali12341 has joined #openscad
ali1234 has quit [Remote host closed the connection]
<teepee>
why different STL just for viewing angle?
guso78 has quit [Ping timeout: 260 seconds]
Andy-pants has joined #openscad
kintel has joined #openscad
<JordanBrown[m]>
gimzmoe: Please elaborate on what you mean by "is there a way to use values internal to a function".
<JordanBrown[m]>
teepee: half a century is, alas, in the rear view mirror, and not that close...
<teepee>
greetings to the other side
<JordanBrown[m]>
I would say "the grass is greener here" or "come on in, the water's fine"... but it really isn't.
<teepee>
haha, will join anyway, soon-ish :)
<JordanBrown[m]>
Getting old sucks. They tell me that it's better than the alternative, but have yet to prove it to me.
<gimzmoe>
JordanBrown[m]: I mispoke a bit, I'm using a module that generates parametric gears, however some internal variables like pitch radius are very helpful for placing the gears relative to eachother. I think I need to create functions that return those variables and use them with the module
<JordanBrown[m]>
Yes, alas, that is pretty much your only option.
<JordanBrown[m]>
PR#4478 will offer some more options, if we ever nail down exactly what it does.
<gimzmoe>
what's the promise for PR#3378?
SenFache is now known as Sauvin
Andy-pants has quit [Ping timeout: 260 seconds]
Andy-pants has joined #openscad
kintel has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
kintel has joined #openscad
kintel has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
castaway has quit [Ping timeout: 246 seconds]
Andy-pants has quit [Ping timeout: 252 seconds]
<InPhase>
gimzmoe: The function approach is the general approach. Consider also you can try: if ($children > 0) { translate([pitch_radius,0,0]) children(); }
<InPhase>
gimzmoe: If you're lucky on your requirements for this, it might make for a handy gear layout option. You could also implement both, and use it when convenient, or not use it when it doesn't work out right.
<InPhase>
gimzmoe: If part of a larger machine, then you'll ultimately probably need numbers to layout everything else attached.
<JordanBrown[m]>
gimzmoe: PR#4478 includes "objects" - what C calls structures, what Python calls dictionaries, and roughly what JavaScript calls objects. They allow you to bundle together data items with names. It also includes geometry as a data item, so that you can take a subassembly and put it into a variable, or into an object, to add to the model at a later time.
<InPhase>
gimzmoe: The 4478 PR is aiming to bring us object literals, so that you can have an object that contains the gear geometry and contains accessible values like pitch_radius.
<InPhase>
gimzmoe: Exact syntax and consequences and so on are still being sorted out.
<JordanBrown[m]>
It would allow you, for instance, to have a function that returns an object that contains both the geometry for your gear and metadata about it.