<OlivierChafik[m]>
peepsalot: what model are you having issues with?
teepee_ has joined #openscad
<peepsalot>
OlivierChafik[m]: hmm? i'm just talking about the same example I pastebinned and also added to your ticket just now
teepee has quit [Quit: bye...]
teepee_ is now known as teepee
<OlivierChafik[m]>
Oh I see sorry. So the issue with that model is the geometry is transformed with imprecise double numbers, which means there aren't that many faces that are actually coplanar when it comes to remeshing
<OlivierChafik[m]>
could either make transforms to use exact numbers, or add some inexact coplanarity test to remesh faces that are arguably pretty coplanar. Not sure how the CGAL triangulation I'm using at the end copes with slightly non-coplanar faces though, might need to call a different one.
<OlivierChafik[m]>
peepsalot: thanks for filing this (and cool color theme haha!).
<OlivierChafik[m]>
Time to sleep for me, take care everyone!
<peepsalot>
np, goodnight. the colorscheme is bultin "Tomorrow" btw
J2273 has joined #openscad
J22 has quit [Ping timeout: 256 seconds]
drkow has joined #openscad
drfff has quit [Ping timeout: 245 seconds]
drkow has quit [Read error: Connection reset by peer]
epony has joined #openscad
arebil has joined #openscad
arebil has quit [Quit: My keyboard has gone to sleep. ZZZzzz…]
GNUmoon has quit [Remote host closed the connection]
GNUmoon has joined #openscad
J227388 has joined #openscad
J2273 has quit [Ping timeout: 256 seconds]
ur5us has quit [Ping timeout: 240 seconds]
ferdna has quit [Quit: Leaving]
arebil has joined #openscad
J227388 is now known as J22
ur5us has joined #openscad
GNUmoon has quit [Ping timeout: 240 seconds]
arebil has quit [Quit: My keyboard has gone to sleep. ZZZzzz…]
arebil has joined #openscad
ur5us has quit [Ping timeout: 240 seconds]
ur5us has joined #openscad
ur5us has quit [Ping timeout: 245 seconds]
drfff has joined #openscad
GNUmoon has joined #openscad
ccox_ has quit [Ping timeout: 256 seconds]
ccox has joined #openscad
<J22>
OlivierChafik[m] here another with cube arrays https://bpa.st/7ECA .. seems it doesn't like faces just touching
arebil has quit [Quit: My keyboard has gone to sleep. ZZZzzz…]
arebil has joined #openscad
lastrodamo has joined #openscad
rogeliodh has quit [Read error: Connection reset by peer]
rogeliodh9 has joined #openscad
ScottJackson[m] has quit [Quit: You have been kicked for being idle]
t-paul[m] has quit [Quit: You have been kicked for being idle]
jochen[m] has quit [Quit: You have been kicked for being idle]
hiredman has quit [Ping timeout: 252 seconds]
hiredman has joined #openscad
GNUmoon has quit [Ping timeout: 240 seconds]
GNUmoon has joined #openscad
la1yv_b has quit [Ping timeout: 256 seconds]
<Virindi>
if I have an array of things such as, [ [foo,bar,1], [fooo,barr,2], [foooo,barrr,3] ] of indeterminate size, is there any way for me to calculate the min/max/etc of the last number? (1,2,3)
<Virindi>
hmm, maybe max() can take an array rather than a list of params
<InPhase>
That's a list comprehension. It's super useful.
<InPhase>
In this example, it ends up producing list [1,2,3]
<Virindi>
thanks
<Virindi>
seems that without that feature, this would be impossible :)
<OlivierChafik[m]>
J22: this is a case where fast-csg bails out of corefinement unless fast-csg-trust-corefinement is set, because so many vertices are shared
<InPhase>
Virindi: Well without it you would do a recursive function. Still possible, but a little more work to implement.
<J22>
OlivierChafik[m] the render still looks ok ( trust corefinement was checked) .. just got a bunch of warnings - however this was part of an other design where this doesn't render and caused trouble.
<InPhase>
Virindi: Here without spaces for compactness. But clearly not too much longer. It just takes a wee bit more thought. function max3rd(v,i=0,m=-1e308)=i>=len(v)?m:max3rd(v,i+1,max([m,v[i][2]])); echo(max3rd([[5,6,1],[7,8,2],[4,3,3]]));
<InPhase>
Virindi: The -1e308 magic number could be removed with undef and special handling for if it's undef.
<J22>
e308 where does that come from?
<InPhase>
The range of a double.
<J22>
ah 64-bit
<InPhase>
Yep. -1.7976931348623157e+308
GNUmoon has quit [Ping timeout: 240 seconds]
GNUmoon has joined #openscad
<Virindi>
god, recursive functions to perform simple loop operations? might as well say it is not possible, because that is too ugly :P
<Virindi>
where I come from, the call stack size is not infinite and pushing and popping is costly! :)
<InPhase>
Well we have guaranteed tail call optimization in that sort of structure.
<InPhase>
So it runs as a loop with a different syntax.
<InPhase>
It's worth getting comfortable with that general approach because while it's longer for this, it's more flexible, and can compute pretty much anything with the right set of parameters.
<InPhase>
Passing along a sum parameter or similar is a common idiom.
<Virindi>
that first link looks like code a professor gave me for implementation in a real program, and it took a long time to even figure out what the variable names meant
<Virindi>
that is the exact opposite of good code :P
<J22>
Virindi just stop using SCAD - Ü it is not for everybody and requires to be flexible in thinking when you are not familiar with that programming
<InPhase>
You can also use it to construct arrays dynamically with more complicated contents and calculations than a list comprehension can do. Thanks to some very clever optimizations, recursive construction of lists by concatenation is actually highly efficient now.
<Virindi>
you think it is a good thing that you have to 'get creative' to perform what would otherwise be simple operations? I am trying to design useful models here, not do a programming exercise.
<InPhase>
Virindi: Well these are all pretty standard operations from languages like Lisp, Scheme, or Haskell, which use recursion a lot more.
<J22>
Virindi you are just not used to think that way - that is all ..
Guest40 has joined #openscad
<InPhase>
Virindi: So it's only "get creative" from an imperative language perspective. It's a common approach elsewhere. But yes, I recognize it's not commonly used in the other language types. Hence the examples. :)
<Virindi>
I want a sequential execution openscad, yes. But for other unrelated reasons, openscad is the best option.
<Virindi>
I am not interested in fighting a holy war, I just want to make models
<Virindi>
I have used lisp before, I have done that stuff before (quite a long time ago though), I just never found it as easy and readable
<InPhase>
And there are various methods within the language to solve problems. But as it's a declarative functional type language, the most flexible of them for calculation use recursion.
<J22>
Virindi the best part is - you getting smarter by using it ( which would be also true for learning a different way of solving problems)
Guest40 has quit [Client Quit]
<Virindi>
you definitely have a different goal for a modeling language than I do.
<InPhase>
The recursive solutions though tend to follow very formulaic patterns that you can get used to pretty quickly.
<othx>
J22 linked to YouTube video "The Art of Code - Dylan Beattie" => 2 IRC mentions
<InPhase>
And once you're used to them, they're not really any harder to read.
<J22>
Virindi i understand that this is puzzling for you - but after you solve a puzzle it is nothing special about if you know the solution. Every new problem is a puzzle
<Virindi>
It is not that puzzling. More it is a throwback to an earlier time and I am not interested in going back to that
<J22>
Virindi - it is ok to think that .. but it is not a throwback, it is just different and for lot cases even more effective.
<Virindi>
I did a bunch of lisp in college, then decided I preferred the other way, and I have not used excessive recursion since
<Virindi>
and also fewer parens :)
<J22>
As i said your brain is just not wired for it (at the moment)
<Virindi>
maybe so, but I don't want to "rewire my brain" just to make a model
<J22>
there is some phyton SCAD converter
<InPhase>
OpenSCAD is a massive brain rewiring already, just to start thinking of all the physical shapes out there in terms of code that creates them. :)
<Virindi>
that is true InPhase, except I never used 'traditional' CAD before it, so openscad is the way I learned to CAD
<Virindi>
now, traditional CAD seems...weird
<Virindi>
you can't modify you models without them breaking all the time, it is horrible!
<InPhase>
I concur.
<Virindi>
your*
<J22>
CSG is not used by most traditional CAD
<Virindi>
I know.
<InPhase>
I think most of the traditional CAD approaches are "doing it wrong", and they don't realize it yet. And I think this approach will dominate in the long run.
<Virindi>
I mean that in traditional CAD, relationships are fragile, because you have just clicked somewhere rather than given a formula. I can't stand that.
<Virindi>
I prefer to give a formula
<J22>
I have SCAD modules that are fragile too if you start changing parameters - Ü
<Virindi>
In traditional CAD, parametric is so much more difficult. In my designs, I can easily change the type of hardware by just changing a single variable. Which I have to, because I often don't know what external parts I will use in advance
<InPhase>
When you want to lay out a modern processor, you don't do it by clicking where the components should go anymore. You write it in a digital electronics language, so that things scale adequately. It will likely become the same for CAD as complexity rises.
<Virindi>
yeah of course, making your openscad model robust is art
<Virindi>
I enjoy it :)
<Virindi>
thinking of every way that different parts can interact
<Virindi>
and adding tests for all of them
<Virindi>
it is also incredibly time consuming, so it is obvious why real product design would not use it
<InPhase>
We just need to continue these efforts in scaling up, until it reaches the breaking point where people can't do it another way because it will take too long. Eventually there will be a diverse collection of programmatic CAD approaches. OpenSCAD I view as simply the first really good one.
<InPhase>
In 20 years I predict we will lose count of the number of decently usable programmatic CAD approaches.
<J22>
in 20 Years you scream at your replicator what you need and it does produce your part
<Virindi>
I seriously doubt it. Most people want to create a model with a single set of parameters as quickly as possible. Graphical CAD wins at that. Also, it is way easier to make nice looking models in graphical CAD when you can simply click an edge and chamfer it
<Virindi>
especially eg. inner corners
<Virindi>
yeah you can do it of course in openscad, it is just way faster in normal CAD
<J22>
Virindi not so sure about this .. if you look at the customizer .. so you can get very nice parts
<Virindi>
of course you 'can'
<Virindi>
it is more laborious.
<InPhase>
Chamfers aren't uncomputable, just not well implemented in SCAD yet.
<J22>
Virindi it is something you use libraries for as this is not in the basic SCAD
<Virindi>
I have been working on one assembly for a month, heh
<Virindi>
most of the time involved has been in different scenarios of interconnected part sizes and how they interact
<J22>
e.g the experimental "roof" is a great bevel tool
<Virindi>
someone using traditional cad aiming for a single set of parts would do the same in a day
<Virindi>
"roof"? /me googles
<Virindi>
no useful google results
<InPhase>
I find most of what I do in OpenSCAD much faster than any human could click through with a graphical CAD.
arebil has quit [Quit: My keyboard has gone to sleep. ZZZzzz…]
<Scopeuk>
cuda acceleration is interesting
<Scopeuk>
and open mp (I had to look OMP up)
<InPhase>
teepee: Looks to be all float based.
<InPhase>
Not sure how complete it is.
<InPhase>
The class list looks a little small so far.
<InPhase>
It seems to promise "exact" for things like right angles, accepting that irrationals are not going to be exact.
<InPhase>
Which is totally reasonable, because that's how it's going to end up for us in the end regardless of how thing are computed in the middle.
<teepee>
yeah, not breaking the meshes seems more useful then theoretical exactness
<InPhase>
I wonder if that Thrust library it's based on works with Zluda, which provides Cuda for Intel GPUs.
<InPhase>
Because I have no desire to buy an Nvidia-based laptop. I've been specifically avoiding them.
<InPhase>
It seems the Thrust library has rejected requests to use OpenCL, the cross-platform approach to GPU utilization.
<InPhase>
So maybe a Thrust-based system is suboptimal.
<InPhase>
It seems Thrust might be an embrace, extend, extinguish type strategy by Nvidia.
<Scopeuk>
cuda is annoying that way, it got a foot hold early on and now its really hard to dislodge
ur5us has joined #openscad
<myosotis>
open standards tend to win out eventually, it'll just be painful until then
<teepee>
sadly not true
GNUmoon has quit [Ping timeout: 240 seconds]
myosotis has quit [Remote host closed the connection]
myosotis has joined #openscad
KimK has joined #openscad
la1yv has quit [Ping timeout: 256 seconds]
<Scopeuk>
cuda was brilliantly marketed, Nvidia threw hardware and software support at academics starting the gpgpu stuff and at the time were technically ahead of opencl, by the time open cl caught up in capability (if not simplicity of use) the academics had released a wall of libraries papers and help that mean industry went the same way
J22 has quit [Quit: Client closed]
J22 has joined #openscad
<Scopeuk>
still infuriating, I have and amd gpu, gpu compute accelerated applications invariably don't support it
<peepsalot>
hmm, bummer about the CUDA dependency for GPU accel. it sounds like thrust still has some functionality for multithreading on CPU but still
<peepsalot>
i've always had nvidia hardware, but lately I'm fed up with their horrible linux driver support
<peepsalot>
I wonder how much effort it would be to have OpenCL support added to that library (or likely a fork since I doubt NVIDIA would be receptive to it)