RefitTrim question

When a surface is split by isocurve, I expect RefitTrim to deliver a perfect result.
See example:
CP_RefitTrim.3dm (142.7 KB)

The edge after _RefitTrim is not where the split happened.
See point.
image

Why is this?

I find refit trim to be a touch dodgy, but if you increase the order/degree it seems to do a much better job.

use the shrink option of _split command.
(not refitTrim)

Not in here.
In this example the deviation is constantly 0.037.
Even with degree 7.

I want to know the cause and solution for the RefitTrim deviation.
How to handle _Split and shrink is known to me :wink:

ok - you re asking of an explanation for the underlaying algorithm. or an wish: refittrim fallback to shrinktrimmedsurfacetoedge if possible (which makes sense). - sorry this was not clear to me in your initial post

Oh goodness, it’s worse than I thought!

Hi Charles -

I see this in Rhino 7 but that appears to be fine in Rhino 8.
-wim

Then I think to have it working in V7 would be nice …

1 Like

I get the very same difference as in V7.
image

Hi Charles -

I’ll need instructions then.
This is what I do:
I open your file and hide all but the surface closest to the origin and the point on its edge. I run Split and pick the Isocurve option and snap to the point. I then delete the small surface. I run RefitTrim and select the new edge on the remaining surface. When I finish that command, the point is right at the new edge. What are you doing differently? And which version of Rhino 8 are you running?
-wim

Look:

The latter command does do it better.

Hi Charles -

image

I’m running a newer version of Rhino 8 than you are:
image

If all goes as planned, there should be a new public build available tomorrow that would contain these changes.
-wim

Hi @wim

Fine when it will be solved for V8.

What about V7?
With such deviations without any chance to get it better the command is more or less useless.

Hi Charles -

This is new technology that won’t be ported to Rhino 7.
-wim

Means _RefitTrim in V7 exists, but is not reliable?
No fix possible?

(The case I described is simplified, in real work the deviations happen all the time.)

1 Like

That sounds terrible… do I really have to keep on using WIP and regulary install / uninstall for to latest wip?
Just to get a usable RefitTrim? Really???

1 Like

Hi -

I’ve created RH-69009 to collect feedback to support a decision to remove the command from Rhino 7. The developer of the feature can also use that information when deciding where to merge new code.
Note that all new features are coded on the Rhino 8 platform, and as the distance between that and the Rhino 7 code base gets bigger and bigger, it gets more and more risky to back port code to Rhino 7. Many people depend on having Rhino 7 as a stable production environment. This late in the development cycle, typically only crash bugs and regressions are considered for Rhino 7.

You don’t need to uninstall and you don’t need to update the WIP more often than you need to update Rhino 7.

I take that as a vote to remove the command from Rhino 7.
-wim

???
Astonishing…
If someone bought an update 6 to 7 (not only) because of RefitTrim, he can expect that it can be dropped without replacement?
Can’t believe I understand that correct.

1 Like

Only if it really is of no use at all as I understand you are saying.
-wim