aiyion1 has quit [Remote host closed the connection]
aiyion1 has joined #openscad
LordOfBikes has joined #openscad
teepee_ has joined #openscad
teepee has quit [Ping timeout: 260 seconds]
teepee_ is now known as teepee
mmu_man has quit [Ping timeout: 252 seconds]
aiyion1 has quit [Remote host closed the connection]
aiyion1 has joined #openscad
snaked has joined #openscad
Junxter has quit [Quit: Leaving]
Junxter has joined #openscad
Junxter has quit [Client Quit]
Junxter has joined #openscad
myosotis has quit [Remote host closed the connection]
kiba has joined #openscad
pca006132 has quit [Remote host closed the connection]
pca006132 has joined #openscad
guso78k has quit [Quit: Client closed]
misterfish has joined #openscad
guso78k has joined #openscad
pca006132 has quit [Remote host closed the connection]
pca006132 has joined #openscad
roleroz has joined #openscad
misterfish has quit [Ping timeout: 252 seconds]
<roleroz>
I just realized that the newest version of OpenSCAD was released on Jan 2021. I see that there is still code being merged in, but I see no releases since then. I checked my installed version and it says 2021.01, which makes me think that OpenSCAD hasn't actually been released since then. Is this the case?, if that's the case, why?
<roleroz>
Will do. I have always used OpenSCAD through the version I installed through apt install, I assume a lot of people do that. Should we have releases at all if they are that old?
<kiba>
I assumed it's a do-cracy
<kiba>
no one's getting paid to do this
<roleroz>
Fair enough
kiba has quit [Quit: Client closed]
kiba has joined #openscad
kiba has quit [Quit: Client closed]
rvt has joined #openscad
<J24k87>
roleroz you have up to date dev releases - but making an official release is done around every 2 years as this is some extra work and we have major changes in the pipeline that needs thorough testing - would be bad to make a release and not to include these new features - would be bad to include them if they are not stable
<J24k87>
the dev releases have very good automatic checks so they work exceptionally well
<J24k87>
And we are close to a RC .. when using the snapshot, enable "edit↦preferences↦features⇒manifold"
<J24k87>
and you get 10× faster rendering
<J24k87>
The dev Team done a great job and putting so much work in it - so it is not so much about "getting paid" - it is a resource problem, either getting a official release or improvements. So the wise man choose to improve, then release
<pca006132>
yeah and the 30% is overall, including things that doesn't benefit much from this change
<pca006132>
so for actual complicated boolean operations it should be better than 30%, probably
<pca006132>
but it also depends on how bad the previous geometry was, as this is changing the collider to make it better towards things that are not axis aligned
<J24k87>
i guess more complex designs are less axis aligned
<J24k87>
or probably even a sphere
<pca006132>
yes
<pca006132>
well, technically it also has to deal with triangle size etc.
<pca006132>
hard to summarize in a few sentences how this is improving performance unless you are familiar with the algorithm inside
pca006132 has quit [Remote host closed the connection]
pca006132 has joined #openscad
pca006132 has quit [Remote host closed the connection]
pca006132 has joined #openscad
pca006132 has quit [Remote host closed the connection]
pca006132 has joined #openscad
pca006132 has quit [Remote host closed the connection]
pca006132 has joined #openscad
pca006132 has quit [Remote host closed the connection]
pca006132 has joined #openscad
pca006132 has quit [Remote host closed the connection]
pca006132 has joined #openscad
fling has quit [Ping timeout: 260 seconds]
pca006132 has quit [Remote host closed the connection]
pca006132 has joined #openscad
pca006132 has quit [Client Quit]
mmu_man has joined #openscad
fling has joined #openscad
fling has quit [Ping timeout: 260 seconds]
mtm has quit [Ping timeout: 246 seconds]
mtm has joined #openscad
teepee_ has joined #openscad
teepee has quit [Ping timeout: 260 seconds]
teepee_ is now known as teepee
mtm has quit [Ping timeout: 252 seconds]
ooxoo has joined #openscad
Junxter has quit [Ping timeout: 252 seconds]
mtm has joined #openscad
oldlaptop has quit [Ping timeout: 252 seconds]
oldlaptop has joined #openscad
ooxoo has quit [Ping timeout: 252 seconds]
Junxter has joined #openscad
misterfish has joined #openscad
pca006132 has joined #openscad
snaked has quit [Ping timeout: 260 seconds]
myosotis has joined #openscad
kiba has joined #openscad
kiba is now known as hackerkiba
misterfish has quit [Ping timeout: 252 seconds]
<gbruno>
[github] t-paul closed pull request #5279 (Add interactive visual feedback when selecting object using the rightClick menu in the 3D view) https://github.com/openscad/openscad/pull/5279
<gbruno>
[github] kintel pushed 4 additions 4 modifications (Reduce Clipper precision by one bit. Fixes #5253 (#5271) * Unify Polygon2d creation * Reduce clipper precision by one bit * Safer handling and assertion of vertices inserted by CGAL's triangulator) https://github.com/openscad/openscad/commit/df9595dea1811407812624b1eaa74ffe43c28e11
<kintel>
I'm a little bit worried that mixing HW z-buffer and SW z-buffer may cause tricky issues in the future
<kintel>
I looked into SW z-buffer a long long time ago, when implementing OpenCSG in WebGL, and I couldn't get it to fly 100%, so I had to go back to HW z-buffer (i.e. all z reads and writes done using the fixed pipeline)
<kintel>
I think the issue was that when moving z values into textures, the values are converted from a proprietary 24-bit value into a 32-bit float, and comparison are no longer the same
<teepee>
that's a bit worrying as the fixed pipeline seems to get more and more broken in newer systems
<kintel>
Even in modern opengl, z read and writes are done using the fixed pipeline, but the vertex shared is responsible for generating the clip space values
<kintel>
that's OK
<kintel>
*shared
<kintel>
*shader (hag)
<kintel>
The issues arise when you _read_ a z value and make comparisons inside a shader and use that to second-guess the HW z buffer
<kintel>
..and the issues may surface differently on different GPUs, since the actual z buffer implementation isn't standardized, AFAIK
<teepee>
right, if there's some internal conversion going on that makes things difficult
<kintel>
Of course, It's possible that the proposed solution is good enough, but it's very hard to tell from just reading the code
<kintel>
I guess the question is also: Will this make it better or worse? More clean or more messy? :)
<teepee>
the examples certainly look great, but that's of course sample size 1
<kintel>
The PR also have a handful of TODO items
<teepee>
I'm not sure how critical those 4 PRs are for the general "interactive viewport" topic
<kintel>
I can dig up my old OpenCSG patch and if we could find a cleanish way of hiding the details, that could be very interesting
<kintel>
How urgent is this btw.?
<teepee>
I hope it's not, I guess it's mainly usefule giving *some* sort of feedback so the interactive stuff does not get tossed due to no feedback at all
<kintel>
I think the pick shader has the same issue as the wireframe shader. I don't know how badly it behaves though
<kintel>
One related thing:
<kintel>
What determines z buffer precision is the near/far clipping planes. Some software recalculate near/far based on camera position and bbox, but OpenSCAD has as fixed near/far. Not sure if that will cause certain types of objects to be more sensitive to the proposed solution
<kintel>
The time consuming approach: Pitch the existing solution against the proposed solution vs. patching OpenCSG
<kintel>
Collect a representative collections of designs, and perform some careful manual testing, look for issues both in rendering and in click behavior
<kintel>
..and hide the implementation behind a reasonable internal API to make it possible to change
<InPhase>
How close to complete is the color render work?
<teepee>
the PR author seems to know opengl well enough it might be worth asking :-)
<InPhase>
All sorts of preview issues can be tossed into the trashcan if we can transcend the need for preview.
<kintel>
InPhase Do you mean the current color render, or the "volumetric color" stuff?
<InPhase>
kintel: Volumetric is my ideal feature, but if we just had comparable functionality to preview color in render color, that would largely obsolete the need for preview.
<InPhase>
I guess we'd lose thrown together, but I don't think that's a huge loss for a codebase simplification.
<teepee>
the data for a more dedicated autocomplete is there, the challenge is wiring this up so it's accessible from the context menu trigger
<kintel>
gotta run. Been lagging behind lately, trying to dig myself out and re-establish some OpenSCAD context; just a lot of things that need love. I'm prioritizing manifold as that's the largest release blocker
kintel has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
misterfish has quit [Ping timeout: 248 seconds]
snaked has joined #openscad
<t4nk_fn>
(fyi, I already had it locally in my 'thoseFrenchThings' branch :b)
GNUmoon has joined #openscad
rvt has quit [Read error: Connection reset by peer]
<t4nk_fn>
personally I'd never use the mouse button in combination with the wheel, but use the alt
<t4nk_fn>
however, I too have found that the alt modifier will only increment, regardless of the direction of the wheel movement
<t4nk_fn>
this is because, presumably, here on linux, using the alt modifier turns the scroll movement from y into the x direction!
<t4nk_fn>
so in that case the "if (wheelEvent->angleDelta().y() < 0)" doesn't work anymore
<t4nk_fn>
"if ((wheelEvent->angleDelta().x()+ wheelEvent->angleDelta().y()) < 0)" would still work in both cases
<t4nk_fn>
but I don't know if this is desirable at all, or using that alt modifier is... but it does fix 'the issue' in any case
<t4nk_fn>
------
<t4nk_fn>
also; this was the kind of behaviour ( the 'previewAfterUndo' thing) that I was sort of looking for before. turns out it was already in there ;)
<t4nk_fn>
it beats editing the numbers and then previewing by hand