Rational Geometry


#1

I’m working on some imported geometry that has several fillet surfaces that are pure arcs (rational). I have to make modifications that involve blending to match these surfaces and am having problems getting good matches, which I guess is because they use weighted control points.

I’ve tried building my blend surfaces using matching rational surfaces, adjusting the cp weight to match but it isn’t giving me good transitions. My next approach is to convert the rational fillets to non-rational.

Is there a generally accepted strategy for this circumstance? I wonder if I’m making hard work of this :slight_smile:

Thanks for any advice offered.


#3

Thanks for suggesting arcblend, not a command I was familiar with. It doesn’t really help on this occasion but might come in useful in the future.

Cheers.


#4

Doesn’t Rhino’s FilletSrf make a surface blend that matches?

It might help to post a small example file with the surfaces that you want to blend between and the blend you want to match.


#5

I simplified things a bit saying blending, the surfaces are more complex that using filleting/blending tools. I’ve been using sweep2 primarily, if not exclusively.

I’ll post a file as soon as the pressure is off, I’ll need to strip out most of it. I was really looking for some guidance on a general strategy for working with rational, perhaps no such thing exists.

Thanks for your reply, jim.


#6

I would extract isocurves with ExtractWireframe, I would blend the isocurves with ArcBlend, and I would re-create the surface with NetworkSrf.


#7

Its hard for me to imagine how a surface that is composed of arcs would be any different than a fillet made of arcs. Are the
arcs variable (not a constant radius).

I wasn’t talking about FilletEdge command which is hopeless for anything that is even a little complicated.


#8

The fillet surfaces are just standard arcs, deg 2 with 3 cps. Not variable, nothing out of the ordinary as far as I can tell.

Which got me thinking - why haven’t I encountered this problem before? I’m beginning to think that perhaps there is something up with the surfaces in this file, or some of them at least. A colleague that I regularly send geometry to via STEP has reported problems, we’ve exchanged hundreds of files without issue previously.

I’ll check it for bad objects and as soon as I can will extract the relevant surfaces to post.


#9

Just to wrap up this thread now that I’ve completed the project and have had a chance to look at the issue again.

There were bad surfaces in the model, not the specific ones I was attempting to match but adjacent. Whether these were the cause of the problems or not, I can’t say for sure. However, since I’ve fixed them, everything seems to be working as expected (including STEP export).

In hindsight, I think I was looking for a more obscure (and maybe non-existent) cause of the issue instead of the obvious. Lesson learnt - keep checking for bad objects as you work (perhaps Rhino should warn when you have them)?


#10

The command perhaps could be added to the list of Idle Processor commands?

// Rolf


#11

The _CheckNewObjects command will put up a warning box when a bad object is created. This command is sticky across sessions.

–Mitch


#12

Excellent. Thanks for the tip, Mitch. I shall definitely use that.

One of the best things about Rhino is that there is usually a way to do anything I can think of, I just don’t know how to do it until I ask here.


#13

I don’t believe that works for opening Step files. I have added SelBadObjects to my open and import button.


#14

OK, I don’t open STEP files much anymore, but in general it is supposed to work when any bad object is created, on import or otherwise… If you have an example of a STEP file with a bad object where CheckNewObjects fails to warn you on import, it would be good to have so the bug can be fixed…

–Mitch


#15

I recall that this was intended behavior. I suppose calling it a bug might get that changed. Any STEP file with a bad object should work to demonstrate the behavior.


#16

OK, would be good to know why that is… --Mitch


(Wim Dekeyser) #17

Have you tried that recently in the RH6 WIP, @jim? If my memory doesn’t fail me, I recall importing STEP files and getting a bad objects report right away. (Then again, it might have come after exploding the block…).


(Pascal Golay) #18

Hi Wim- I am pretty sure that is the case, I’ll see if I can dig up a Step that has one of these, I know I run into it once in a while.

(Chuck tells me that this is by design - opening with no error messages - so that the import process does not get hung up on a bad object dialog)

-Pascal


#21

@pascal - this is completely wrong behavior, and I have mentioned this at least a few times in the past. The current implementation of CheckNewObjects is to pop up the dialog the instant a bad object is created, and suspend any running process until the user clicks OK. That’s a really poor UI implementation. You guys have some of the best developers in the world, you can’t tell me that it’s not possible to just count (flag) the number of bad objects while an import (or any other operation!) is in progress, and once the operation is complete, then throw up the "Bad objects " dialog just ONCE. :astonished:

On top of that, the dialog may have been supressed for STEP imports, but it’s not for 3dm files - as far as I recall, if you import or open a Rhino file with bad objects, you still get the dialog you have to OK for each object. I haven’t tested this in the WIP though.

Thanks, --Mitch


#22

If I remember correctly they already have told us that.


(Chuck Welsh) #23

File IO plug-ins are a special type of plug-in with a different definition from others. I believe that they automatically suppress the bad object message. That would be every file type except for 3dm. It’s easy enough to keep track of bad objects from withing the individual plug-in code and fire off a message at the end. I’ve done that for STEP in the next WIP. I don’t know what’s involved in changing the system to do this automatically(not my area). It’s certainly possible, but may take a major rewrite.

The way I’ve done it, there is just one box to dismiss at the end, rather than one for each bad object.

It should work just like the nested block warning. You decide at the import dialog box. This setting is independent of the over-all show bad objects setting. It only affects STEP import.