Hello rwblodgett!
I have to say this is one of the more interesting use cases for the engine I’ve heard of so far :).
If I’d just think a bit about your first idea, to launch the engine as a subprocess to your own and then using IPC to control the environment, I don’t see any insurmountable obstacles to getting this to work, although you could probably not leverage everything the engine has to offer. For example, any static lighting would probably be hard to make work since that generally requires you to first build your level, light it and then build the lightmaps for the level, which is an extremely expensive operation and not something that you would do during run time. Considering the info you have given me, I’m guessing you guys own some type of visualization software, like architecture visualization or scenario simulation or something like that. If this is indeed the case, this is probably something that you would want to have.
One alternative to this is making all lighting dynamic. If you were to go this route, you would not suffer the light building cost to the same extent. There are however other features, that like the static lighting requires design time processing, like Mesh Distance Fields or content processing etc.
Let’s then assume that you will not use any of the other run time processing features and that you would solve the content processing by doing it piecewise on demand, or having declaration files that you would process in a batch job when you launch the engine or the like. You still have quite a few number of problems after that though, like making your meshes and materials available to the engine. The meshes I think might be rather straight forward. UE4 has quite a few mesh importers in the engine. The only thing you really have to watch out for here is that you cannot use those importers outside of the editor context, as I think I’ve read in some thread that using editor/engine components in your own code breaches the terms of use unless your customers also have the engine. This might however have changed since engine access became subscription free. If this is something that you would like to do however, I would definitely look into the rules before I make a decision either way :D. In the worst case, you could probably construct dynamic meshes at runtime, it’s actually been a rather popular topic in the forum for a long time now! Check out this thread for example:
The biggest downside with this is probably an additional performance cost, but I don’t really know to what extent.
When it comes to materials, it becomes a bit harder though. All primitive components in the scene are rendered using materials defined in uasset files. Those are in the end HLSL shaders, so there might be some way to make them run without having to create them in-engine. I haven’t seen anything about this however, but I do know that there are material importers in the engine for the content pipeline (the fbx importer is a good example if you want to have a look: https://docs.unrealengine.com/latest/INT/Engine/Content/FBX/StaticMeshes/index.html ) although using that solution would expose you to the same terms of use problems I talked about in the previous paragraph.
As I’m assuming you’re mostly interested in placing static mesh actors with high quality materials and then manipulating a camera around that scene, I get the feeling that if you could solve those two problems, I think the rest might be pretty straightforward. If you want interactivity / AI / triggers and all that other good stuff, there is nothing I know of that cannot be created/controlled from C++. You could easily make everything you need on the UE4 side of the IPC channel and then spawn them on demand.
But then there is the question if this is a good idea, or if there is a better one. I think if I was tasked with solving this problem, I would much rather reverse the relationship.
That is; I would host our application inside the engine somehow. I would design and create all the blueprints, meshes, materials, particle systems and base levels I needed in UE4, and then I would write a small plugin or just project source that would parse my business domain files and populate the scene in accordance with them. If our app had a preexisting GUI, you could still make it work easily by either just sharing the data models through IPC, or by using file watchers. Trying to bypass the content processing and creation features in the engine just seems like a lot of unnecessary work to me 
But then again, I know nothing of your system! 
**tl;dr;
I definitely think what you are suggesting is possible, but you might face both logistical, feature related and legal problems to have a chance at making it work decently well.
My recommendation is to invert the relationship, using the full feature set of UE4 in conjunction with your current application through a common data model.
To answer your leading question though; Yes. I think that UE4 is a good fit for any project that aims to have impressive visuals, from prototyping to full products. Since you have the full source that is also fully C/C++ compliant, you can basically make it work with any setup you can imagine.**
I hope you found this useful in some way.
Best regards,
Temaran
