-
Notifications
You must be signed in to change notification settings - Fork 11
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add multi-frame output to capture sand changes over time #46
Comments
Love the idea of using a fan to transform the dune landscape! Please make sure to send some updates from your workshop. For performance reasons, you'd probably like to have it run as part of the main component. Having an additional option in |
Should this be part of SandWorm 1.0 release? |
Implement multiframe capture; closes #46
Curious about the workshop results @philipbelesky. Care to share any insights and photos of the forms you ended up modelling? |
Most of the workshop ended up being pretty standard applications of the table as the 'wind' devices we had brought along were either far too weak or far too powerful to do a good simulation of drift. The multi-frame output was useful as a way to capture a 'build up' of landform over time by someone who was looking at a dredging/deposition process. Once students' projects are a bit further along there might be a few follow up sessions with a chance to further refine the models/techniques used in the table. |
The use case here is to be able to scrub backwards in time in order to examine how the sand/mesh changes over a particular period. The immediate use case I have for this is an analog simulation of dune drift (basically by way of pointing fans at the sand). For that purpose, I would want to capture a sequence of meshes over a given time period to visualise the change and be able to perform analysis between the different states. This would likely have value in other forms of simulation — e.g. a Cantrell-style setup for fluvial processes.
Being able to set the tick rate helps here, and data dams help further, but it would be ideal if the
outputMesh
list was able to be added to by successive solves rather than replacing each solve. That should be easy enough, my question is whether it should be in the main component (with an additional option inSandWormsetup
? I'm imagining a simple IntegerParameter along the lines of 'stored frames' which, if set, appends new meshes tooutputMesh
up to a certain size. If that size is hit, the earliest items in the sequence start getting removed.I'm running a workshop with this use case in mind this week, so should be able to sketch out an implementation and PR based on how that goes.
The text was updated successfully, but these errors were encountered: