- User Since
- Jan 18 2016, 12:14 PM (335 w, 5 d)
May 10 2022
Interesting, if disabling particle resampling has some artistic benefits, then yes we can totally add this.
Before though, I'm trying to think of side-effects we could run into. From the top of my head:
- Liquid volume loss will happen more often (should warn user about it)
- Need to hide UI fields that won't do anything anymore (such as 'Particles Maximum / Minimum')
- the narrow band probably won't work
Nov 9 2021
Nov 7 2021
There are 2 things that triggered the crash:
- Normals of beach obstacle are pointing inwards.
- Beach and pusher create airpockets in the domain.
Oct 2 2021
Oct 1 2021
Sep 24 2021
Sep 13 2021
Sep 12 2021
Sep 10 2021
Sep 6 2021
Aug 10 2021
Aug 9 2021
@Brecht Van Lommel (brecht) Yes, sounds like a reasonable solution.
Aug 4 2021
Aug 3 2021
Jul 26 2021
Jul 21 2021
Closing, committed in rBadefdbc9dfa3.
Jul 19 2021
Removed OpenMP patch. No longer needed after OpenMP version upgrade.
With new OpenMP patches/openmp.diff seems to be no longer needed and applicable. @Ray molenkamp (LazyDodo) remove it?
Jul 14 2021
Jul 8 2021
Jun 22 2021
Jun 21 2021
+1 Sure, no problem
Jun 18 2021
Just committed the optimization for the for-loop (rBadefdbc9dfa3).
The optimization for if (phi.isInBounds(isysIdxS + 1)) ... I haven't committed yet. It didn't give me a speedup (correct me if I'm wrong) and think it's a bit more readable as is.
Jun 14 2021
That's a nice improvement! I even think that this kind of loop optimization will be useful in other parts of the manta code too.
We should place it in a more generic container so that it can be used everywhere (e.g. plugin/secondaryparticles.cpp has similar for-loops with radius offsets).
May 27 2021
May 25 2021
+1, geonodes should always be considered non-static
May 18 2021
Running macOS with AMD graphics here. I am not seeing the issue, all good for me.
May 17 2021
Apr 29 2021
Apr 22 2021
Apr 14 2021
Apr 12 2021
Apr 3 2021
Mar 29 2021
Mar 26 2021
Mar 24 2021
Mar 23 2021
@Marc (Polyflogger) It seems this issue comes from OpenVDB and blosc (v1.5.0) directly: A build with the latest blosc (v1.21.0) has no problems whatsoever.
Mar 20 2021
Mar 18 2021
Hi together! It looks like this problem comes from the OpenVDB compression.
Until this is fixed, can you try using a compression method that is not "Blosc" (Cache -> Advanced -> Compression Volumes)?
One thing: macOS arm64 currently uses different versions for LLVM and OpenMP (rB21236af80c8e).
make source_archive_complete will not fetch these when creating the archive on a system != macOS arm64.
Mar 17 2021
Just ran this too. LGTM, have nothing to add to the discussion.
It's unclear to me why this landed without proper testing a day before bcon2. We should have tested this patch with the upcoming macOS arm buildbot and functionality directly on arm devices.
Mar 16 2021
Mar 12 2021
Mar 11 2021
Mar 9 2021
Didn't see any issues either!
Mar 8 2021
Mar 5 2021
Mar 4 2021
Thanks for the explanations and the patch.
Mar 3 2021
@Phil Hargett (hargettp) ARM libraries have been updated, so after make update builds should work again!