Open GoogleCodeExporter opened 8 years ago
Can you provide a simple example, or a Maya command I can run to create a NURBS
surface which demonstrates this problem?
Original comment by miller.lucas
on 28 Jul 2014 at 5:44
I have attached an example. Simply exporting it to .abc and importing it back
will show the problem.
The FormV will change from 'Periodic' to 'Open'.
Thanks for looking into it.
Best,
Steve
Original comment by steven.s...@gmail.com
on 28 Jul 2014 at 6:42
Attachments:
The logic which detects that formV is Periodic is working correctly, however
MFnNurbsSurface::create is failing with an "Unexpected internal error".
If the initial create fails, it is retried as open/open. This may be a
precision issue with Maya's NURBS surface logic.
Original comment by miller.lucas
on 28 Jul 2014 at 7:34
Thanks for the quick turnaround. We'll see if I can generate a simple test
case, and maybe send it to Autodesk.
Thanks,
Steve
Original comment by steven.s...@gmail.com
on 29 Jul 2014 at 2:53
Hi Lucas,
After a few more tests, I think the problem might be that
MFnNurbsSurface:create requires double array for uv knot sequences, but
AlembicImport is feeding it with a double array converted from float array.
My guess is the maya api checks the number with double precision, but the
number provided only has float precision(+/- 0.0001%), so it doesn't pass the
check to qualify for a periodic surface.
I did a quick test by manually adding precision to the uv knot numbers, and I
was able to call MFnNurbsSurface::create without error.
Please see the attached file for the data I used.
span_9_uv_range_1.txt contains the numbers I captured from AbcImport. Feeding
those numbers into MFnNurbsSurface::create causes it to fail.
span_9_uv_range_2_althered.txt has more precision digits manually added to v
knot values(other data is the same), and MFnNurbsSurface::create works.
'recreate.py' is a quick script to read the data file and recreate the
nurbsSurace.
Thanks,
Steve
Original comment by steven.s...@gmail.com
on 5 Aug 2014 at 9:56
Attachments:
That data certainly makes it look like precision issue.
Since many other packages represent NURBS data as floats, I wonder if they
would be willing to relax that check.
If not, then we may have to live with the current behavior.
Original comment by miller.lucas
on 5 Aug 2014 at 10:07
Original issue reported on code.google.com by
lih.hwa....@gmail.com
on 22 Jul 2014 at 8:51