Quality of Fusion generated surfaces

[cekuhnen]

Here is the Alais model left with the Fusion import back in Alias

The Fusion model data is pretty heavy. I used loft (No rails)

[nogeelen]

Did You loft in Fusion and then import to Alias, or did You import from Alias to Fusion export the surfaces and re-import to Alias?

Cheers, Norbert

[deyop]

Claas,

There are really two different approaches to defining the digital surfaces.  The priority for the Alias surfaces will be for a minimum number of controls to enable direct modeling.  This is the approach that has evolved over many years of supporting customers who generally have highly trained users.  They are aware of surfacing strategies and the basics of NURBS surfaces development.  When you import those surfaces and extract curves to use as input in Fusion you are now working with a system that is based on accurate solid modeling requirements.  The reason there are so many controls is to enable that accuracy.  There is never any expectation that the curves or surfaces will be modeled directly.  What is surprising is how similar the results are even with a different modeling system.  For many the results would be indistinguishable.  Quality has to be defined based on some criteria.  If quality is in how few controls there are then the Fusion results won't compete.  If the requirement is smooth surfaces then the results are pretty close and could probably be improved even further if the curves had been generated natively in Fusion.

It would be difficult if not impossible to enable workflows that would support bi-directional transfer of geometry between two different modeling approaches.  This is not a new problem.  The integration of Alias surfaces into solid modeling systems has always been a challenge with bi-directional transfer extremely limited.

Our approach has been to enable sophisticated organic shape development primarily with T-Splines in the Sculpt workspace.  The goal was to lower the barriers to developing sophisticated shapes that many people can't approach with surface modeling.

I'm certain that Fusion's future will incude advanced surface modeling that would include tools and approaches that would be similar to Alias.  I am not sure that adding all of those capabilites within the core of Fusion would be the best approach.  It may be better to provide a workspace dedicated to that approach.

I hope I didn't read too much into your initial observation but the bottom line is that these surfaces are developed in two significantly different modeling systems.

Thanks

[cekuhnen]

Hi Paul. I understand that somewhat the code in each engine is different. But this reads as Alias is not as precise as a Fusion surface. If Fusion adds so many spans to blow up the surface, why not using degrees and not spans because it is common understanding that spans are an aspect to try to limit as much as possible.

Does this with Fusions Kernel not matter? Also I found some interesting different results.
So when I loft three profiles the Fusion result for Alias terms is extremely obese.
But if I rail it the surface is spot on 1:1 as in Alias with the Rail tool.

Based on your explanation each result in Fusion should be quite different but they are not which is why I found this interesting to investigate.

And please excuse me for asking this from my perspective, but isnt the goal to have a math easy mesh and a surface with too many spans is complicating the design?

The Main reason I ask for is when the input curves are fine, the surface skinned with it should be fine as well.

So here I build something natively in Fusion and the export in Alias is pretty much the same (lower right). The span density seems not to be so excessive,

well the shape is not as curvy so I might assume thats the reason for it.

so adding more curvature to the splines ( 2 fit points) shows a significant increase in spans but not as drastic as in the first image.

so I am curious if for certain operations the loft comand simply added too much data.

[deyop]

Here is a bit of a clarification after discussing with one of our ASM (Autodesk Shape Managment) team.  In Fusion the modeling system is generating a procedural body.  A representation that is defined internally for ASM.  This improves both the speed and accuracy of the results.  The surface internally is not explicitely being defined as a NURBS representation.  When you output that procedural surface in a neutral format or even the .wire format the procedural surface is being fit with a NURB representation because the recieving system doesn't directly read the procedural ASM model.

So building the model in Fusion will only yield the NURBS result you are displaying in Alias after a fit when outputting in another format.  The number of spans is only a function of the translation.  We don't expose the tolerance of the translation (I believe it is 10 to the 3rd). 

[cekuhnen]

Hi Paul,

Thank you for the explanation. That makes sense then.

Could at one point there be a way to expose this? The main reason is simply because for data sharing.

When sculpting a product tollerance is sometimes needed for mechanical parts but not alwas the most important

when have some room for differences.

In this case it would be great if I could move data and use each app for what they are good for.

Sofar most times the workflow is one way - surface to engineer app. But sometimes like in SolidWorks I feel

handcuffed and would like to go back and forth.

I understand that this might not be so easy technically speaking, I am just curious.

Claas

[deyop]

We discussed this and it is possible that a tolerance could be exposed but reducing the tolerance won't necessary produce results that are going to support your direct modeling strategy.  Fitting is often based on algorithms that are notorious for ignoring user insight about creating "light" surfaces.  I think our best strategy will ultimately be integrating surface modeling strategies that recognize the value of light control networks and managing transitions manually.  

[cekuhnen]

Hi there, I see your point and agree. Surface rebuild are always tricky it is nearly an impossible problem to solve of you do not want to have sacrifices.

I guess that's why I am so persistent on burbs curves with CVD. Between alias and rhino I can send the date easily.

Now my question is if the math kernel fusion users world even support burbs and CVS for curves.

Inventor has silliness with CVS but are this nurbs curves or is this diverging different?

[cekuhnen]

Omg I wrote this being outside in the cold with shaky hands on a smartphone. Some of the wrong word I did not see. Please excuse

[cekuhnen]

Loft rail makes OK surfaces keeping it the same lofting alone created this
heavy surface in fusion.

Importing alias into fusion and exporting back into keeps the surface the
same

So I would say a simple fusion loft here created the span madness