Closed mariuszhermansdorfer closed 3 years ago
What were you imagining the implementation here looks like? To my mind this is probably worth having a dedicated component for, and it could live downstream from the main component without a significant performance penalty.
Essentially the inputs would be something along the lines of MeshA
and MeshB` and the job of the component is to determine the differences between them. Those differences might drive cut/fill calculations, or a visualisation of how they differ with an eye to building a spatial overlay that directs users to shift sand in order to minimise the differences. Depending on how orthogonal those tasks are each could be a separate component.
What exactly that spatial overlay looks like would be an interesting design task — Bison provides a good precedent here although could be improved if the purpose is to guide users in sand-shifting rather than just visualising a Rhino model on its own.
I was primarily thinking of the sand shifting part. For more elaborate comparisons, one can always use Bison's component. Plugging it downstream of a live SandWorm component is very slow, though,
Therefore I was thinking of having this logic as part of our mesh coloring routines. Basically, another type of (exclusive) analysis, which would be selected from the right-click menu. My idea for the implementation would look like this:
samplingMask
, which is the size of trimmedWidth
x trimmedHeight
samplingMask
by a scale factor corresponding to the size of the physical model in the sandbox.samplingMask
at the desired location on top of the terrain mesh to be sampledsamplingMask
. If difference is negative - colorize with red color ramp. If positive - colorize with green gradient.The above approach should result in instantaneous feedback. If we wanted, we could easily add some sort of volume estimates as well. Have two variables to track a running sum of cut and fill respectively and convert these to real-life units such as m3 or cft.
I'm struggling with finding a good way of passing data of different types between the SandWormOptions
and SandWorm
components. So far it is an array of double but this is somewhat limiting.
How would you approach passing the above described samplingMask
along all the other variables? I can't see anything useful in the official methods.
I would just create a class/struct that contains the key/value pairs and pass an object with all the different values. If you use AddGenericParameter
you can send/receive arbitrary objects; for instance the (very underdeveloped) Groundhog planting components both send and receive a PlantSpecies
class that inherits from GH_Param<IGH_Goo>
.
And yes, adding the delta by colorizing the mesh would be a great and easily-integrated solution. There might be some value in additional information atop the color mesh (e.g. the exact height differences in text?) but that could be dealt with as a geometry-outputting analysis type if it ends up being useful.
First sketches started in this branch.
Users can define a rectangle of any size and orient it at will over an existing mesh. The grid of sample points is being created automatically based on the data from SandWormSetup
and an additional ScaleFactor
slider.
Still need to add the actual sampling logic, but wanted to share the progress.
First prototype ready. Initial calibration (#40) is almost ready as well. Will tweak a few things and merge to master soon. Quick demo video here
That looks great! Manipulating the sand so that the mesh shifts from green/red to white seems like a very zen game.
Added a completely redesigned CutFill analysis mode. Not affected pixels are marked dark grey:
Just provide a mesh which overlaps with Kinect's FOV and hit the reset button.
We can also reuse SandWorm's meshes for further analysis. Here it's a 1:1 comparison without any changes:
With my hand for comparison:
The color gradient range slider helps to tighten/loosen the accuracy.
Code in this branch: https://github.com/mariuszhermansdorfer/SandWorm/tree/feature/CutFill2-0
Does this suit your requirements @philipbelesky?
I just realized, that all lookup tables for vertex colors get recalculated at each tick.
Here we create new instances: https://github.com/mariuszhermansdorfer/SandWorm/blob/1a59f98bbd9b08ae39205fb5c23312524f0b6f4e/SandWorm/Utilities/Core.cs#L331-L333
hence our lookup tables are always null
and this condition is always true:
This is the case for all analysis types: https://github.com/mariuszhermansdorfer/SandWorm/blob/67da1b4b50f98d5f01a10eead3f0333825a26d09/SandWorm/Analytics/Elevation.cs#L23-L27
@philipbelesky do you have an idea on how to fix this? Ideally, we'd set these to null
while resetting.
Added support for custom color palettes and tweaked the default one as well.
Now, when users switch to the CutFill
analysis type, the palette changes automatically. Vice versa, switching to the Elevation
analysis type, changes the palette to the previously selected one.
Here is the relevant code: https://github.com/mariuszhermansdorfer/SandWorm/blob/d9e428a761b8e565e0f7c24083c6677fae68edf3/SandWorm/ComponentsUI/SandWormComponentUI.cs#L211-L225
Added support for spot elevation display as an additional option while working in the CutFill mode. This closes #58
Added basic statistics available through the stats
output. It calculates volumes in cubic centimeters regardless of chosen model unit. I find it most intuitive to work with, rather than having massive amounts of mm3 or tiny m3.
Pure cut scenario:
Pure fill scenario:
Mixed scenario:
Ad-hoc cut/fill balancing:
Combined with tight label spacing, one can get quite close to the desired value. Working with higher Averaged frames value gives slightly more consistent results.
Add option to recreate an existing terrain in sand based on GIS information. This could also be used to graphically visualize cut & fill differences between design iterations.