Volume Compensation D.LOFT request

This is a reasonably complicated technical request to explain, so I will try and keep it simple!

When using D.TOOLS to create faceted surfaces from a compound curved surface, it is obvious that volume will be lost if the curves used for the develop-able strip are not ‘larger’ or partially outside the target volume.

This is explained to some extent in the demo about making develop-able strips for hulls https://www.youtube.com/watch?v=KNdA4AH4f4A

In the demo, it is explained that the rough mesh must be enlarged somewhat to compensate for the loss in volume. As the flat planes will end up intersecting the inside of the curved target surfaces.

With this in mind, I think it would be great to have two tools to help with this …

  1. An analytical tool that compares the surface area of the original target surface with the developed surface
  2. An automated option, that could work out how much to move the mesh edges used for the develop-able surface in order to end up with the same surface area as the target surface.

I don’t think that is very well explained, but I hope it makes sense!?

Thanks

I have a question regarding option 2: Would that mean that D.LOFT should not loft between the given input curves (and approximate them within the given tolerance), but rather move away from the input curves?

Hi,

Not as default…

In the options that are currently there (tightness, deviation tolerance, align with edge etc), there could be another option for volume compensation which would do this calculation prior to creating the develop-able surface

Hui, that’s a very hand-wavy specification.
I think what you want to achieve is a globally best approximation of your input surface with developable strips. Such a best approximation will always roughly halfway intersect the input surface, the curves of the strips will certainly not be on the input surface.
We know how to do such approximations and have the necessary global optimization tools to do it available in our in-house plug-ins, but this is certainly not in a condition to be released as a publicly available plug-in for Rhino.

What you could do as a brutal, rough workaround:

  1. Do the strip approximation once.
  2. Use closeness analysis to measure
    the max positive/negative approximation distance.
  3. Offset the input surface accordingly, and redo the strip approximation.

Aha … on that note, I have been seeing some errors with the closeness tool that I don’t understand… This is a copy and paste of an email I sent to Alex yesterday…


I wonder if you might be able to identify why I have these unusual results from the etAnalyzeCloseness tool.

The view is from underneath a tensile form (rhino file attached test tent roof 002.3dm (5.8 MB)) – I have used the develop tool to make the surfaces you can see in the screen shot. I then set the main tensile mesh as the reference, and selected all of the faces made using D.LOFT to be analysed with the ‘closeness’ tool.

I expected the results to be similar to the three panels on the left, where the blue stripe shows the obvious distance from the rounded form very clearly, but all of the other panels seem to have a common, rather ambiguous measurement, rather than individual for each panel?

As far as I know the panels were not created any differently to the three that share an expected result.

Also, the closeness figure is way out, I measured the deviation manually to be around 15-25mm from the ‘mould’ shape, but the readout gives 2230mm which is obviously totally incorrect.

Also, on the panels that do appear to be analysing correctly, the colour scheme appears to be the wrong way around (as I read it) – The blue is the smaller gap, which should be at the edges, but it appears in the middle which should be the greatest gap!?

Hope you can help me understand the problem here.

Many thanks

Hi, here comes the solution, which I admit is not so obvious:

  1. etAnalyzeCloseness by default measures distances boundary-to-boundary and surface-to-surface, that’s not what you want in this case. Change this behavior using etOptionsToggles DefaultBoundaryCloseness=Off.

  2. etAnalyzeCloseness used with surface uses the render mesh and vertex-colors it according to the distance measured. If your render mesh is very coarse, that’s a problem. Go to Options → Mesh and make sure your render meshes are reasonable dense, e.g. by specifying a maximum edge length.

Hi snabela,

Great, thank you for taking the time to help me here!

Cheers!

OK, changing etOptions Toggles to defaultboundarycloseness=off sorts out the inverted results, but I still only get the same three panels giving expected results (not like in your example).

I have my mesh setting to smooth/slower, what maximum edge length would you recommend?

Cheers, Andrew

Please make sure that your max edge length for render meshing is significantly lower (e.g. 1/10th) of the max strip width, then it should look as expected.

Hi, OK, understood. Thanks.