Removed until it can be placed in an Unreal Subscriber only environment.
I congratulate you on figuring this out!
There are legal issues surrounding this however,
I had already priorly asked about including the FBX sdk on the AnswerHub and got this response from Epic:
Summary
If you use the FBX sdk you can only share your resulting product with other licensees of UE4, it cannot be released to the publicAre you positive this applies? The quoted post seemed to relate to releasing this asset creation functionality to the public who purchase your product, not for tool creation within Unreal itself by the developers who have licensed Unreal 4. We are after-all using the FBX tools within UnrealED at production stage, where one would assume the Unreal license covered usage of the FBX tools within the editor itself in much the same way that the actual FBX importing would be, all that would be released to the public would be the created unreal assets, no one except Unreal licensees could actually use the above.
More that Joe Public is not licensed to use the Unreal SDK and therefore releasing tools for them to use the FBX SDK within an in-game editor would not be permitted. The only people using the FBX stuff I detail here would be coders and artists on Unreal game projects that would presumably have to have a license to have access to the editor code anyway.
Would love to hear from Epic about this.
The comment about Unreal code however is interesting, would love to know if my code posting (being altered and only useful to Unreal licensees, but probably a shade bigger than 30 lines) would be okay since I think it would be useful to the Unreal developer community.
Cool with deleting if so but would be a shame.
Yes I am positive my AnswerHub post is relevant,
right here:
#include “FbxImporter.h”
#include “FbxMeshUtils.h”
#include “PackageTools.h”
Because this comes from the Editor section and not the Runtime, all the legal issues apply, as mentioned by Cannon in the answerhub post
But again, I am still congratulating you on figuring all of this out!
Great Work!Thanks! tho I don’t think you see my reasons for being sceptical about this. 
“Using FBX importer in your editor would mean your editor is based on Epic’s tools (anything from /Engine/Source/Editor directory), so it would only be permitted to distribute to other licensees.”
This is implying that your end product, the ‘create your own game’ thing you’d release to the public would have to contain the FBX Importer. You would be releasing to the general public binaries based upon /Engine/Source/Editor files. And thus your product would be based upon Epic’s tools and therefore only distributable to Unreal licensees who were permitted to use those /Engine/Source/Editor libraries.
What I have above is a method for developers to edit Epic’s tools with the source code license they already have, to allow them to create assets for their game. The public would never have the contents of /Engine/Source/Editor in the final product. The only ones who would have have it are licensees. This surely only applies to you because you were asking if you could release content creation tools using Epic’s tools as part of your product itself. Despite having created a custom editor, you would still be distributing Epic technology to anyone who purchased your ‘make your own game’ editor in the form of dlls that are only for developers who are licensed.
“so it would only be permitted to distribute to other licensees.” applies to the method described above, which is indeed only of use to other licensees. We would not be distributing FBX importing functionality as part of the finished product. To suggest we’re not allowed to even use anything in the Editor part of the codebase seems to make no sense to me, otherwise why would they provide the source code in the first place. Adding extra functionality to the editor using the provided source code to aid development is obviously a permitted thing, no?
I’m willing to admit you may be right, but it sounds like a rather crazy licensing rule that pretty much invalidates the entire point of providing the editor source code, which is presumably done so that developers can create additional stuff in the editor to suit their particular development needs.
Ooooh I see now 
Again, congratulations on figuring this out!
But I am leaving my above comments in place for other readers to be aware that this is for Editor-only for legal reasons and cannot be made part of a game / finished product.
So do think of my posts as an addition of info, rather than something detracting from your post.
I am actually very impressed by your post and can’t wait to see what you come up with using your awesome method!
Enjoy!
Thanks 
well hopefully we’ll get some clarification from Epic on the matter! No worries about detracting from the post it’s good to be careful about such things.
I forgot to mention, I also applaud that you are sharing this info with the Community!
With such sharing we can all do amazing things together as Community of UE4 C++ Programmers!
[FONT=Comic Sans MS]
hi its ok if i ask can u post a simple project (no assets) just how project with what u said look alike i have hard time set that up heheh
Hi lemmy101,
Is there a way of adding normals data or smoothing normals for shading?
Thanks
Hey fuzzybro! It’s using the FBX SDK, therefore by that very nature anything that is exportable into an FBX from a 3D modelling package is available to you. As to how to do any particular thing I cannot say (I’ve been sidetracked on other projects since that post) however reading the FBX SDK documentation ( Autodesk FBX SDK Documentation ) should allow you to do practically anything you desire providing it is possible to store in an FBX file. Which is obviously a yes to the two examples you give.
Thank you for linking this! these are some of the answers I was looking for
Well it’s only say that you can’t use the FBX integration done by Epic in your game at runtime. You could make your own importer dll with the FBX SDK, that way you don’t use Epic code and still can import FBX at runtime to support mods and everythign else.
This is an interesting use of the FBX SDK in Unreal, that’s for sure! I’m curious what cool benefits you get from using the FBX APIs to construct geometry in the editor versus creating mesh assets directly.
You are mostly clear on the legal side. This is because your editor customization is only useful to other Unreal Engine subscribers which is a valid use of the license. It is similar to distributing source to an editor plugin that you’ve created.
However you should not paste Epic’s FBX importer code to the public forums. Remember that access to these forums is not limited to UE4 subscribers, and the license only permits small “snippets” of UE4 code to be shared broadly. Instead, you should create a GitHub fork and link to your fork here, as only other subscribers will have access.
–Mike
Thanks man!
One more thing that I haven’t figured out yet is how to create multiple materials?
By default imported meshes have 1 material.
I tried adding another material but no matter what I do there is only one material per mesh.
No problem Mike will look into doing this now. Will remove the code in the meantime until I can get this set up.
re: your question. It’s mainly so we can ‘replace’ raw artist power with procedural generation editor side, which I think is an extremely important thing for indies with limited art team. Run-time procedural generation seems limited in support in UE4 atm but I’m sure that’ll improve, but more importantly game side procedural generation runs the risk of being a blob of content that soon gets repetitive. Once you’ve seen one town you’ve seen them all. Once you’e seen 20 buildings they all feel the same etc.
Doing it editor side means we could create 1000s of buildings very quickly, and then spend time decorating, landscaping, placing or editing them specifically within unreal. We can get the code to take them as far as humanly possible and this means an artist requires less time working on that building.
Editor side we can quickly create huge swathes of world, create buildings in code, and then with a more limited art team be able to augment the results to provide a more ‘hand built’ world while still levering the procedural generation. In particular it means that we can iteratively improve a huge world starting quickly with a generated world. Only way we can really compete with the big boys/girls given how big AAA art teams can get. 
So basically the advantage is some C++ is given the power to do the job of artists we aren’t in a position to employ, and though obviously the results would never be what we could expect off an experienced 3D artist there are plenty of things we can do programatically to cut the artist workload dramatically. This is our thinking anyway.
I’ve been doing a similar thing, only outside the Editor using the Python scripting extension for the FBX SDK. It’s probably a faster (in terms of coding time) approach than grinding it out in C++. After this thread, I’m not at all sure about posting the code.
Hello you!
I think that’d be fine the problem was posting Unreal code - posting your python script would be totally ok I think.
And, Hello right back 
Well, the code I’m using now has gotten pretty hairy; I’m using it to generate tracks for a racing game. The origin of it was basically this Gist…
I think your approach has one major advantage - you can stick metadata (basically, any data) into FBX files for processing by the engine. It might be a route to inject all kinds of things into it…
So what happened to this? I found this thread which I had hoped would be exactly what I need, only to find the code is all gone 
I am working on writing an Alembic importer so while this isn’t directly the same, I was hoping it would give me more insight on how to go about creating a StaticMesh from code in an editor plugin.