legoman and technoid have separately reported anomalies that we believe we recognize (here and starting here). I'm starting a common thread here that will include a suggested workaround.
High-level summary:
We think this is not a new issue, exactly, but has probably always been lying in wait and is only now able to be seen. After some investigation we are currently uncertain of the exact cause and whether it's actually a RealFlight issue. There is a workaround that is a bit annoying but consistently successful.
Details:
Our team put our heads together today to look at the above reports and we think we know what's happening in these cases.
To quote from a previous post:
That alone is enough to potentially lead to differences between earlier versions of RF and DX11-based Evo, depending on how the normals are set in a model. If they are very close to what RealFlight would have generated on its own, then any discrepancy would be difficult to detect. On the other hand, to the degree that they differ, things could look quite different in Evo compared to earlier RF versions. Note that "different" in this case does not mean bad; the new result should be a more accurate representation of your source art in RealFlight. But it definitely could be confusing or alarming if comparing results from different versions.
With that change in place, we have encountered an issue that occurs somewhat regularly with rotated parts of a 3D model. One of our artists, Ted Graves, wrote up the following explanation along with instructions for correcting the problem. @legoman, @technoid, and anyone else making custom content for Evo who encounters this type of issue, please try the following.
The problems in these screenshots look like an xforms normal issue to me.
In the past our fbx import code would completely recalculate the vertex normals of imported objects. We made a change recently to properly import the vertex normals of imported files to give artists more direct control over their work. Naturally, this exposed some preexisting problems that we couldn't see before.
This issue is one we've run into as well that we're still sorting out. It has to do with the way vertex normals are calculated on objects with rotated transforms. It appears in 3ds Max as well, so we theorize that it may be an internal issue with some modelling apps.
Here are the steps to fix it in 3ds Max. We'll use an aileron as an example.
High-level summary:
We think this is not a new issue, exactly, but has probably always been lying in wait and is only now able to be seen. After some investigation we are currently uncertain of the exact cause and whether it's actually a RealFlight issue. There is a workaround that is a bit annoying but consistently successful.
Details:
Our team put our heads together today to look at the above reports and we think we know what's happening in these cases.
To quote from a previous post:
That alone is enough to potentially lead to differences between earlier versions of RF and DX11-based Evo, depending on how the normals are set in a model. If they are very close to what RealFlight would have generated on its own, then any discrepancy would be difficult to detect. On the other hand, to the degree that they differ, things could look quite different in Evo compared to earlier RF versions. Note that "different" in this case does not mean bad; the new result should be a more accurate representation of your source art in RealFlight. But it definitely could be confusing or alarming if comparing results from different versions.
With that change in place, we have encountered an issue that occurs somewhat regularly with rotated parts of a 3D model. One of our artists, Ted Graves, wrote up the following explanation along with instructions for correcting the problem. @legoman, @technoid, and anyone else making custom content for Evo who encounters this type of issue, please try the following.
The problems in these screenshots look like an xforms normal issue to me.
In the past our fbx import code would completely recalculate the vertex normals of imported objects. We made a change recently to properly import the vertex normals of imported files to give artists more direct control over their work. Naturally, this exposed some preexisting problems that we couldn't see before.
This issue is one we've run into as well that we're still sorting out. It has to do with the way vertex normals are calculated on objects with rotated transforms. It appears in 3ds Max as well, so we theorize that it may be an internal issue with some modelling apps.
Here are the steps to fix it in 3ds Max. We'll use an aileron as an example.
- Unparent the affected aileron, and unparent all of it's children.
- If the aileron has a custom pivot, create a cube, and use the Align tool to copy the pivot of the aileron to the cube. To do this, enter adjust pivot mode. (Fig.1) Select the cube, click the align tool, then select the aileron. Make sure it's set to the Align tool and not Quick Align. (Fig.2)
- In the dialog that pops up, check the X, Y, and Z axis in the Align Orientation (Local) section, then hit ok. (Fig.3)
- Select the aileron and reset the XForm by selecting Reset XForm from the Utilities tab, then clicking Reset Selected. (Fig.4)
- Select Edit Normals from the drop down menu in the Modify tab. (Fig.5)
- Select all the vertex normals for the aileron and then click Reset. (Fig. 6)
- Convert the object back into an editable poly again, and transfer the pivot from the box back to the aileron using the Align tool like we did in steps 2 and 3. Delete the box.
- Reassign parents and children to the aileron.
- Reexport the FBX and reimport to RealFlight.
