Community
FBX Forum
Welcome to Autodesk’s FBX Forums. Share your knowledge, ask questions, and explore popular FBX topics.
cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Inconsistent Handling of Ambient Lights on FBX Export from Maya and Max

6 REPLIES 6
Reply
Message 1 of 7
Anonymous
1361 Views, 6 Replies

Inconsistent Handling of Ambient Lights on FBX Export from Maya and Max

Hi there. I would like to call attention to a little inconsistency in FBX's handling of ambient lights from Max and Maya. I'm writing a game engine that parses ascii FBX files to load our lights and various other objects, and I've run into this problem.

The FBX exporter warns you on exporting of an ambient light from Maya that they are not supported in the file format, and that they will be exported as a Point light with "Visibility" set to 0. This is fine, as all we need from the ambient light is a color and an intensity, both of which get exported. Our parser just flags any point lights with a 0 for visiblity as an ambient light and handles it accordingly.

This behaviour is not consistent with Max however. Max doesn't explicity have an "ambient" light type, but instead a "Skylight". A Skylight is essentialy the same thing as a Maya ambient light and has a color and intensity, again both of which get exported into FBX. It is also not supported and results in a warning on an FBX export and gets converted into a point light. My problem is the "Visibility" parameter does not get set to 0 by the Max exporter, so there is no way for our parser to differentiate a Skylight ambient light from a regular Point light by looking at an ascii fbx file. We use the 2010 6.1 format, but this issue exists in all of the newer ones too (just tried the 2013 plugin and ascii file format). For the time being we're using a manually set "ambient" User Definition to identify the skylight as an ambient but we would love to see the next release of Max FBX exporters handle this case either the same as the Maya ones do or a clearer universal solution applied (eg an Ambient bool parameter, flag or light type added to Light nodes). If this change could be applied to the older formats too that would be fantasitic as we'll be sticking with the 2010 format for as long as we can as its much simpler to parse as text. Thank you for your time.
6 REPLIES 6
Message 2 of 7
Anonymous
in reply to: Anonymous

Hello VicariousEnt,

The behavior you're describing is incorrect. I am logging a bug for it and the fix will be in our next release. Unfortunately, it will not be in older formats of the plug-in, it will only be available as of the next one which will be 2013.2.

Thank you for bringing this issue to our attention!

Cheers!
Carlos
Message 3 of 7
Anonymous
in reply to: Anonymous

Awesome.

I didn't mean I wanted you guys to re-release the old plugins, but if the 2013.2 plugin could apply this change to the 6.1 2010, etc formats as well that would be fantastic. We always use the latest FBX plugins, but we use the drop down menu to select the 2010 ascii format when we're exporting objects that our in engine parser will be handling (lights, entities). Would that not be desirable to you guys? To go back and fix this bug in the older file format too since the current plugin still supports the older formats?
Message 4 of 7
Anonymous
in reply to: Anonymous

My apologies, I misunderstood.

You will still be able to use the drop down in the settings menu to set your preferences, such as 2010 and ascii format so that your files will work with older versions of the software.

As a side note, in case you weren't aware, if you find yourself with FBX files that are not 2010 comaptible, you don't have to go into Maya and resave them in order to convert them to 2010, you can use the FBX Converter which is a free tool that lets you load multiple files at one time and batch convert them. You can find it here, it's on the same page as the plug-in.
http://usa.autodesk.com/adsk/servlet/pc/item?siteID=123112&id=10775855

All the best,
Carlos
Message 5 of 7
Anonymous
in reply to: Anonymous

Will this fix be in effect with the 2013.2 exporter if we select the 2010 format on export though?

While I've got your attention, one other problem I ran into when getting our lighting engine up and running with FBX files is the "Specular" checkboxes in both Max and Maya don't make it into the FBX file format in anyway. Direct 3D and I assume Open GL require extra setup to turn on the specular component of their lighting model, and its off by default as its expensive (or at least it used to be considered so). The native lighting model in both Max and Maya allow you to turn off a lights ability to cause specualar lighting to occur, it would be nice to have that flag passed on via FBX. D3D even allows a seperate Specular color and power for its lights in addition to the Diffuse color, but just knowing whether a light should produce specular lighting would be enough. This of course isn't a bug, but I think it should be a part of the SDK, if even just to maintain the light settings properly when exporting between Max and Maya. I've checked the 2012.2 format and it doesn't address this either but I'm not sure about the 2013 changes.
Message 6 of 7
Anonymous
in reply to: Anonymous

Hi again VicariousEnt,

To answer the first part of your post, yes, the option to export in 2010 format will be available with the 2013.2 plug-in. You'll find it in the drop down menu under Adanced Options of the FBX presets.

As you said in your post, it is really only Maya, Max and Softimage that let a user decide whether a light emits diffuse and/or specular. Since FBX is a plug-in that is meant to transfer data between many softwares including MotionBuilder and Mudbox, only the physical light properties (i.e. color, intensity, cone) were considered when the scope of the plug-in was being decided. That isn't to say that a future version of the plug-in will not have the option, but for now it isn't possible. I will talk to the lead developer to see if a suggestion can be logged to have it done for a future release.

In the meantime, there are a couple of things you could do, although they are perhaps not easiest to implement:
1. You could write an Extension to the plug-in to add functionality to the original.

2. You can define some custom user properties to control the emissions, but you would still need to run a script (mel/maxscript) to connect the emission properties at moment of importation. The plug-in can handle custom properties, but it won't be able to handle the expression linking the property to the light attributes. The script should be pretty simple to write, I was able to get one working in Python for Maya without to much difficulty. I'm including it here, one locator controls diffuse and spec emission for 6 spot lights.

import maya.cmds as cm

allLights = cm.ls(lights=True)
for light in allLights:
cm.connectAttr ('locator1.DiffuseEmit', light + '.emitDiffuse', f=True)
cm.connectAttr ('locator1.SpecEmit', light + '.emitSpecular', f=True)

Hope this helps,
Carlos
Message 7 of 7
Anonymous
in reply to: Anonymous

Thanks for the help.

We've already added specular and ambient User Definition tags as a workaround to get these 2 things working and our engine importer just looks for the keywords. Importing lighting profiles back and forth between Maya and Max isn't a concern, we only go from one or the other to our engine in regards to lighting. It would still be nice if the specular checkbox got into the format at some future date though. Thanks for your time.

Can't find what you're looking for? Ask the community or share your knowledge.

Post to forums  

Autodesk Design & Make Report