<ali1234>
what would be great in blender is... an object type that is backed y an openscad script instead of a mesh data block
<ali1234>
just type what you want, heh
<ali1234>
this would also mean that blender functions as an openscad ide since it has a built in script editor
<ali1234>
so you could write some scad code and then apply a blender modifier to it, use it with instancing, apply shaders...
<ali1234>
blender's new geometry nodes are pretty cool and can do a lot of things openscad does, but it seems not yet possible to do things like extrude and minkowski
<ali1234>
the only problem with this idea is adding a new object type to blender is extremely difficult for no particularly good reason. you have to touch like 100 source code files to do it
<dalias>
:-p
<ali1234>
then there's the details like how to specify blender material slots in openscad. that could be done with attributes i guess :)
The_Jag has quit [Quit: The_Jag]
default_ has joined #openscad
sublim8 has quit [Ping timeout: 268 seconds]
default__ has joined #openscad
default_ has quit [Ping timeout: 260 seconds]
<JakeSays>
i've never used blender
ochafik has quit [Remote host closed the connection]
ochafik has joined #openscad
ochafik has quit [Ping timeout: 268 seconds]
<InPhase>
JakeSays: They're great when you want a smoothie.
juri_ has joined #openscad
ochafik has joined #openscad
<InPhase>
peepsalot: So nobody broke the rands. The detailed_tree still works fine, just in my rush to test this morning before leaving for work, I forgot teepee edited in an anim bool at the top, turning off the animation. :) It turned out my design did not depend on the rands refreshing themselves each run, because I seeded the sparkles on $t.
ochafik has quit [Ping timeout: 260 seconds]
<InPhase>
peepsalot: Which does in fact mean that a design which seeds part of the way through cannot achieve unseeded rands on repeated runs. This is an edge case, but it seems one worth addressing somehow. Ideas that pop into mind: The quick hack would be a magic seed value, like nan, undef, or a string, which tells it to re-seed with the clock at any point the user wants. Or, always seeding with the clock
<InPhase>
before each new run. Or, a new random number generator value type for max flexibility, acting like a built-in function literal type (the hardest solution, but more empowering).
<InPhase>
Repeatedly reseeding with the clock is one of those things that's hammered into your head that you're not supposed to do because it's very predictable and non-random. But maybe OpenSCAD is an exception case to this rule?
<peepsalot>
i mean, that's important if you're doing crypto, but I don't think relevant for openscad users
<peepsalot>
InPhase: the thing i don't get, which I was just testing, is if you have one file open with non-seeded, and another file in the same process using seeded, the seeded one doesn't interfere with the non-seeded in that case
<peepsalot>
i figured the issue would be that the generator was some kind of global, but apparently not? what is the lifetime/context of a random generator in openscad?
<InPhase>
It's global.
<InPhase>
deterministic_rng in func.cc
<InPhase>
So it does interfere if you are consistent in running the seeded one, the unseeded one, the seeded one, the unseeded one.
<InPhase>
If you run seeded one, unseeded one, unseeded one, seeded one, unseeded one, unseeded one, then the first unseeded runs in each set will match, as will the second unseeded runs in each set.
<InPhase>
Which is of course what seeding is supposed to do per program. Just in this case, "program" should be the scad files, and not OpenSCAD.
<InPhase>
It's easy enough to add a reset_seed function into func.cc, but I guess I'm not sure exactly where to call it.
<peepsalot>
ah, i see the pattern now. so it just keeps generating from the seed, with like subsequent seeded values for each unseeded run
<InPhase>
Right.
<peepsalot>
i think just set if from clock at the start of CSG compile?
<peepsalot>
*set it
<InPhase>
I was thinking we had to do it for command line also, but of course we do not.
<peepsalot>
maybe depends if animation is done from command line, i haven't tested since that was added
<InPhase>
Oh, right... Yeah.
<InPhase>
Hmm. Also, func.cc is weird. There's no header, because nothing includes this stuff.
<InPhase>
The rng went there because that's where it's used. But these functions are weird self-registering functions with BuiltinFunction.
<InPhase>
I guess I can repeat the absurdity in builtin.cc and do an extern void reset_seed(); directly in MainWindow?
ur5us has quit [Ping timeout: 268 seconds]
GNUmoon has quit [Ping timeout: 276 seconds]
ccox_ has quit [Ping timeout: 260 seconds]
ccox has joined #openscad
JoyaDK has joined #openscad
<JoyaDK>
Another day, another question XD
GNUmoon has joined #openscad
<JoyaDK>
My rendering stops (stands still) at 937/1000. Anybody knows why and what to do? (Win64)
<JoyaDK>
Do I just have to wait longer (be more patient)? XD
<JoyaDK>
Problem solved *duh* I need more patience... Sry for the stupid question
<InPhase>
peepsalot: Well, the first round reseed attempt had undesireable results. The reseed algorithm in use was using time(), which only changes once per second. So short designs yield the same result multiple times in a row. That was fixed previously because the process ID was being mixed in, but when you reseed within process, it means the process ID doesn't change so both time and process ID are the
<InPhase>
same.
<InPhase>
peepsalot: This might require tapping into one of the higher resolution clocks, or an alternate approach such as seeding from a second RNG which is itself clock + process based.
snaked has quit [Quit: Leaving]
ochafik has joined #openscad
ochafik has quit [Remote host closed the connection]
<InPhase>
Yeah, that should do it for the first of those two options.
<InPhase>
I guess I could even do both.
<InPhase>
Make a seed_rng seeded by high_resolution_clock, then at the start of every computeCSG, reseed deterministic_rng with the output of seed_rng.
<teepee>
there's not much guaranties regarding resolution but I would expect it's more then seconds at least :)
<InPhase>
That approach would guard against resolution issues.
<InPhase>
Since I can still mix in the process ID as well.
<teepee>
yeah, and not much more code
<InPhase>
It would then be basically impossible to ever not be seeded randomly.
<teepee>
right, room for later extension by a --initial-seed option :)
<InPhase>
It looks like mt19937 has the sequence-seed initialized as well, so I can set that to more than 2^32 sized seeding with that much data.
<InPhase>
s/initialized/implemented/
<InPhase>
Officially that's the mt19937ar seed variant, which allows up to 624 32-bit values as a seed, corresponding to the size of the internal state vector.
<teepee>
hmm, looks like high resolution aliases to system clock, not steady clock even with same tick period :(
<InPhase>
And if we're being pedantic about edge cases, steadiness will only matter if we're repeatedly resampling from it, so if we use that seed_rng approach, high_resolution_clock is a fine bet.
<InPhase>
If nothing else jumps out at me I should be able to get that out tonight. It sounds like only a few lines on top of the few lines I already tried, plus testing.
<gbruno>
[github] t-paul closed issue #3775 (Consider dropping macOS 10.9-10.11 support to update Qt and enhance experience on current macOS versions). https://github.com/openscad/openscad/issues/3775
<InPhase>
bomb: And much hackery went into this one... But here's lf94's hand, in case you need to biometrically identify as lf94 some day: https://imgur.com/a/AzSq2c6