No announcement yet.

VRay FBX Importer not working

  • Filter
  • Time
  • Show
Clear All
new posts

  • #16
    Full rundown:
    Maya 2012 hotfix4 & 2013 SP2
    Standard FBX Loader as far as I know. If I open up Maya's plugins panel in 2013, the fbx loader says it is version 2013.1 for API version 201300.
    Windows 7 (We could test on OSX as well but have not yet because SpeedTree is on Windows for us and our Macs are not heavily involved in the 3D pipeline)
    The only plugins enabled in Maya are the standard fbx plugin, vray, and mental ray.

    I just checked the windows 7 app install wizard and it lists "Autodesk FBX Plug-in 2013.1 - Maya 2013 64-Bit".

    I also just tried uninstalling that to see if it makes a difference, but Maya seems to still say it's using 2013.1. I don't know if this makes a difference.
    Perhaps you can see if this matches what you see, and in the meantime I'll try reinstalling our Maya 2013 and see if it decides to behave. Unfortunately I need to use these versions of Maya, these guys haven't upgraded past 2013 yet.

    Edit: Repaired Maya installation, no love, then uninstalled / reinstalled, also no change.
    Last edited by maxnbk; 07-01-2014, 07:13 PM. Reason: updated info


    • #17
      Okay, so, I got it to work, in Maya2012. It's using FBX 2012.1.1 , and it took at least *and hour and 20 minutes* to perform the import action. The shaders in the hypershade look black, but rendered from VRay the tree shows up as it should. This isn't normal I assume, seeing as a standard FBX takes about 1-2 minutes to import normally.


      • #18
        That one at least has a solid answer. Update your FBX plugin. You can get the latest one here:

        The stock Maya 2012 FBX plugin was super slow. Not sure why. But the update fixes it.


        • #19
          Sorry to burst your bubble, but after the update, maya 2012 still took the same amount of time to import.
          I also tried an update to Maya2013's FBX from the same area on Autodesks site, and it did not change the previously mentioned errors.


          • #20
            Well, we were able to verify that it's a system-specific thing here.
            We had tried 3 machines and each of them did not work, but a fourth did.
            It has the same version of Maya2013, the original FBX plugin, and nothing else special about it.
            But I did notice that FBX files show up in the Windows interface as having the the special "This is an Autodesk FBX file" icon, whereas on at least one machine, it just looks like a generic maya icon. So I think that the system itself is somehow thinking that it's not an FBX file. Which makes absolutely no sense. But I have no other explanation so far.

            So in the mean time I'm trying to figure out how to get Windows to re-associate fbx files the way the other Windows machine has. Which I have no idea how to do, but I'll see what happens.


            • #21
              Problem solved, finallyyyy.
              So I don't know where this is comes from, but it would seem that the OS-native file browser versus the Maya-specific file browser elicits different behavior. If I use the OS specific file browser, it seems to attempt to base the FBX plugin and settings used on what the most recently used FBX import preset / settings is, and therefore attempts to use the wrong plugin if the regular maya FBX has been used. If I use the Maya-specific file browser, it will use the correct (specified, whether maya or speedtree importer)
              As an effective way of solving the problem, if encountered, I suggest going to Maya prefs, deleting all FBX importer/exporter presets, and deleting maya prefs to return to defaults and then import with the Maya specific importer.
              I believe this may be able to be fixed on the plugins end by having a specified FBX settings included with the script that gets loaded by the FBX importer, although I don't know the flags to make that happen.


              • #22
                Glad you got it working. Perhaps that is why we couldn't reproduce it here.

                I'll log to look into if we can work around it.


                • #23
                  Other similar note: The current version of the SWA importer is broken in a severely easy way to fix. The importer script has code that refers to the file that it is attempting to register as a plugin (aka itself), pointing to an old name for the plugin, being "". That's not what the file is named anymore, so if you replace every instance of "" with "", the script will no longer fail to load. I can't say if that breaks anything else, because it's the first time I've gotten it to load, but I'm guessing that's an innocuous enough fix overall.