Is Unreal right for us?

We already have a desktop application that does a lot of things. We already have a 3D engine based on opengl.

We’re thinking of incorporating unreal as our new 3D engine, but still work integrated with our app.

We might even consider going so far as having our application communicate with sockets/named pipes with the 3D engine Unreal in a separate app, if Unreal only allows itself to be created as an EXE.

However, is there a better way?

We already have all our assets as 3D geometry, either static, or procedurally created. So I was thinking we’d need to inform the 3D engine exe to spawn all our entities as actors.

We don’t really care about the editor tools or content creation tools, etc. We would procedurally create our levels based on what our users setup.

We do like the visuals.

Is Unreal Engine right for us?

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: ) 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 :slight_smile:
But then again, I know nothing of your system! :smiley:

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, thank you for the detailed reply!

Would having all lighting dynamic be a performance hit?

I think we’d pass in all the raw vertices and try to create procedural meshes out of everything, taking the performance hit there, and then associate our descriptions of materials with preexisting materials in the engine. I assume we can load in our own textures and place them dynamically on meshes too.

Good to know

We have quite an extensive asset processing automated system already. The idea of reprocessing all these assets in the engine itself manually doesn’t seem practical to us. Since this is a moving target, and these assets are updated monthly in some cases.

Thanks for the information. Good to know it’s so powerful and extendable. So, a tangential question to this thread. So, is there a place I can launch some communication threads at the very beginning initialization of the application? So far I’ve only seen ways through all the tutorials to tie into Players and Actors. But what if I want to start my communication threads first thing? Or would I always put in a default invisible “Character” that would be my communication link?

Hello :slight_smile:

Most definitely. One of the things that really makes UE4 impressive is their usage and implementation of the Enlighten static lighting system. You can check out some videos here:

I’m not an expert on this system by any stretch of the imagination, but as far as I understand, the idea is that you can bake static lightmaps, and then using enlighten you can get extremely realistic looking dynamic lighting effects using that static light data. Since dynamic lighting is very expensive when you start including more amounts of light sources, reflection etc. it is almost essential to use something like enlighten if you want to be able to render real time. If you are only interested in scenes using a static camera, then maybe you could get similar visual results without using enlighten / static lighting data. Your framerate would probably take an extreme hit though :slight_smile:

I don’t think I’ve ever seen anyone try this though, so this is pure speculation. If you are interested in more info on this topic, I recommend posting a thread on this in the rendering forum, the guys and gals there will be able to help you more :slight_smile:

Ah, I’m guessing you mean you will import your materials and then do associations, yeah, that might definitely work. You can definitely load textures on the fly, yes. If you want to set them to your material interfaces during runtime, you will have to create MID (material instance dynamics) though, so you should check that out.

There are some caveats, like you cannot do it on non-movable actors, and a few minor bugs, but they can be worked around :slight_smile:

I see… if you have a large library of assets, but not many asset types, maybe writing custom importers might be a good compromise?

Well, the best way would be to use a plugin if you want to “get in early”. You can even choose at which phase you want to get loaded and execute. Check out the LoadingPhase property on this page:

>> PostConfigInit allows the module to be loaded before the engine has finished starting up key subsystems. PreDefault loads just before the normal phase. >>

If you want concrete examples on how to make plugins that load at these stages, you’re welcome to check out my renderdoc plugin project at:

To solve the graphical subsystem hooking problem (renderdoc’s IAT hooks need to be attached before all the shaders etc. are processed, so it is essential that I initiate it early enough) I’ve basically made two plugins instead of one.
The loader plugin is loaded as early as possible, letting me init renderdoc and thereby setting the hooks.
The “real” plugin is then loaded in the default loading phase, and it takes care of the actual user interface and interaction stuff.

Hope this helps :slight_smile:

Best regards,

I wish unreal had enlighten, but enlighten is for global illumination, not static lighting. Using their patented dark magic, they can pre compute the “radiance” of static geometry. When lighting its then placed in the scene, the secondary bounce lighting is much cheaper to perform. As far as I know, it wouldn’t make the direct movable lights any cheaper.

And dynamic/movable lights do cost a bit more, but it shouldn’t be too big of a problem. If you can help it, use stationary or static. With those you can use lightmass to precompute the bounce lighting like enlighten…you just won’t be able to move the lights like enlighten.

If you would like to use enlighten, you have to buy that separate. The video is just a demo of what it would look like.

I did not know that!

Thank you for the clarification :slight_smile:
I suppose I unconsciously assumed that it was integrated after seeing the demos and reading a lot about it. I definitely need to study the lighting system a lot more it seems!
I suppose the best way for rwblodgett to proceed might be to just try both and benchmark? A well scoped test might give enough info to choose :smiley:


Why was this posted “C++ Gameplay Programming”?

Should have been posted here surely?