PonyDeluxe / alembic

Automatically exported from code.google.com/p/alembic
Other
0 stars 0 forks source link

Maya Export Import Nurbs with periodic form issue #348

Open GoogleCodeExporter opened 8 years ago

GoogleCodeExporter commented 8 years ago
What steps will reproduce the problem?
1.Create Nurbs surface with span greater than 8 and UV range from 0-1 with a 
Periodic form
2.Export the alembic
3.Import back the alembic to maya now the Form is Open

What version of the product are you using? On what operating system?
1.5, linux

Please provide any additional information below.
if the spans is under "8" it will do the correct things.
if is not under 8, the min max range UV needed to be 0 to spans cant not be 0-1.
otherwise the form will flip to open instead of periodic or close.
just wondering is this actually an expected behavior?

Lih

Original issue reported on code.google.com by lih.hwa....@gmail.com on 22 Jul 2014 at 8:51

GoogleCodeExporter commented 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

GoogleCodeExporter commented 8 years ago
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:

GoogleCodeExporter commented 8 years ago
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

GoogleCodeExporter commented 8 years ago
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

GoogleCodeExporter commented 8 years ago
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:

GoogleCodeExporter commented 8 years ago
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