Announcement

Collapse
No announcement yet.

Unreal Engine as a Service for Developers

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    Unreal Engine as a Service for Developers

    Unreal Engine as a Service for Developers
    If we were to run Unreal Engine as a service on developer machines (workstations) it would allow us to focus on specific tasks rather than have to deal with the inconsistencies of the unreal editor interface.

    OS integration
    Unreal Engine already running similar to a virtual machine as like Java would allow many possibilities and enhance workflow.
    An example is that someone who boots the editor now, just to work with the content browser, has to deal with the main editor window for no reason. This must waste resources when it’s sitting underneath many other sub-editor windows.
    If this were implemented there could be a toolbar and the popup on the taskbar item for opening each of the sub-system’s editors, of which, the level editor window would become one, like kismet and generic browser.
    It would also function better with the taskbar in the OS because each sub-editor's window could be stacked on top rather than being hidden from the taskbar inside of the main editor window.

    Tabbed browsing in Sub-Editor windows
    It is my experience that Unreal Editor suffers from the “too many windows syndrome”. While people who work with the editor might commonly have more than a single monitor, screen space is a commodity in this industry.
    As an example, not only could we save on the cost of multiple monitor setups if they aren’t required, we can also save screen space which means people can be more productive on the space we’ve saved.
    This could also save resources because we can deactivate rendering in tabs that aren’t visible currently, such as multiple static meshes being open at once in the associated sub-editor.
    The recommendation is that each sub-editor automatically supports tabbing with the ability to drag tabs out to windows if required. This way, materials would always be stacked under the material editor window, static meshes under the static mesh viewer window and so on.

    Not only is productivity an issue but so is the time factor for poor navigation method through windows and sub-editors. The goal here is to enhance workflow so that what people really want to use is right there with minimal “digging” around required.

    IDE access to the Service
    The ability to compile whilst the editor is open is a much sought out feature for many, having Unreal Engine running as a service opens up more possibilities than this simple ability.
    If the packages are cached for the service and the service can unlink them for compilation, then an IDE can be run alongside the Unreal Editor. Caching of materials and the content browser could be done at intervals rather than on boot.
    IDE’s with access to the service could use the package cache for auto-completion not only of keywords, modifiers, enumerators and the like but also for assets in package groups. This would greatly enhance efficiency by allowing people to link to their assets from within Unreal Script.
    The ability to compile while the service is available only compounds the benefits to this solution, allowing people to work with both the art pipeline and programming pipelines alongside each other almost un-interrupted. Unlike the current system which you have to open the editor, check the asset path, put it into your Unreal Script, remember to close the editor and then recompile.

    There is so much to be gained from this simple idea, it all came from seeing the main window get continuously stuck on the bottom and the other windows getting stuck inside it even on multiple monitors. Not only that but with the discussion of multiple IDE’s being developed for Unreal Script and what they can provide over Visual Studio sparked my thought on the topic.

    Materials as Sub-Expressions
    The idea here is to allow people to use materials within materials so tasks like creating custom lighting modes or shading techniques across a whole project is easier.
    Any changes to the Sub-Material would cascade through all materials using this so global changes to lighting would be much quicker.

    The sub-expressions would mirror normal materials and exposed options could be set within the material allowing connections to only nodes that allow it.
    A benefit to this would be something similar to the already implemented Material Instances if you pull in a material and only modify acouple of nodes with exposed nodes defaulting to preset values.
    Output nodes for channels like diffuse could be labelled as such and modified before being plugged into the channel of the super-material.


    I realize the magnitude of this task in terms of a redesign and that people might be partial to the old methods because they have just learnt it or it’s what they know. Looking towards the future I only see good things for Unreal Engine and I would like to be part of that future.

    There’s a lot more that could be done with this and this is just the tip of the iceberg, a couple that quickly come to mind is closer integration with the Swarm sub-system. Since Unreal Engine would be run as a service this turns each client running the service into a potential render node. Or the ability to run command line scripts through the service much as you can type into the command line box in the lower left of Unreal Editor.

    Thank you to everyone who has helped me over these years, to the guys on #unrealscript irc, to all of you here on the forums and most importantly Epic Games.

    #2
    Surely as a service it's going to be consuming rather a lot of system resources, even if we're not using a particular component?

    Comment


      #3
      It may be because I am currently sleep-depraved, but I am confused, what is this thread? Just a strain of thoughts about the engine?

      Comment


        #4
        On the idea of OS integration--being able to use the content browser isn't something that can be done by itself---since it needs the engine running to be able to display the objects (even as thumbnails) so I don't think it would make things run faster. Also, your point in that is so you can save resources by only opening the one thing you need to use rather than the whole editor, but my question is, why do you feel you need to save resources that way? I mean, I can even run 3ds Max and Photoshop at the same time as UDK so it's not like it's going to improve anything much.

        Comment


          #5
          Originally posted by Graylord View Post
          I'm a bit tired, but I am confused, what is this thread? Just a strain of thoughts about the engine?
          I'm 10 and what is this?

          Comment


            #6
            That was supposed to mean...?

            Comment


              #7
              It's an internet meme. But yeah, Viper is pretty bang on. You're going to need a lot of the application running at all times to deliver many of the features of UDK. Other things, such as inclusions into the shell aren't that useful either.

              Comment


                #8
                It would be nice, though, to be able to have it "always running" while working, and being able to update/compile, have it pick up the changes, as well as being able to launch the game (like PIE now), bring up an editor viewport, have a content browser, even have an accessible API (something that I think had been planned a long time ago, but never really happened, if I recall from reading some of the docs on the file formats) for gathering information from the engine. As well as having all of the tool windows as their own task bar item, and able to be individually minimized, maximized, etc, with maybe only a toolbar showing above everything else.

                As is, the interface is a bit annoying to deal with sometimes, when you have several different components open all at once. One thing that has been bugging me lately, is that although it is entirely possible to have multiple object properties pages open, you have to open them all at the same time, yuo can't open one, then open another, it will replace the first one that was opened (at least, as far as I know). It'd be nice to not have a giant main window that occupies the entire screen space, when what I'm really in the editor to do is examine a SkeletalMesh's bones and AnimTree.

                Comment


                  #9
                  The point of this thread guys is to generate discussion on these ideas since I know full well I havent thought of everything. So please keep the thread ontopic even if you dont agree that these ideas are worthwhile to implement.

                  Ambershee, as a someone who works with UE Im sure you can appreciate that most of us have alot of UE running most of the time anyway. The statement about saving resources was purely in regards to tabs as thats the subheading its under not a blanket statement for the whole proposal.

                  The main goal here is one of productivity and enhancing workflow to save, screen space, time and money. Also making it easier to intergrate third party applications and scripts into pipelines, allowing automated tasks.

                  We have to wait for unrealed to boot currently, for it to cache, to build, compile but as a service we could take advantage of those extra processes on workstations while they arnt being used. It really isnt a question of pure resources

                  Edit: Blade, thats another good idea the properties window could use that ability. You can understand where Im coming from with this the game, the compiler and the editor will all boot multitudes quicker, not that its slow (it can be at times) but itd certainly be worth the extra resources in the long term.

                  To go alittle more indepth on the topic of resource consumption by a service lets consider how the engine works, right now it can load and unload assets and it needs, objects can be automatically garbage collected. The editor uses a similar collection of resources shared across all sub-editors, while render windows are overlapped. To that end I dont see the service hogging memory if it doesnt need to or stealing cpu if it really doesnt need to, there will be overhead like any service but it wouldnt be more then running a software firewall, antivirus, java or anything else. If you need resources they are ready to be opened straight away even predicitively cached by the service so that the assets you use more often are given higher priorities.

                  Comment


                    #10
                    I don't even know that it really needs to be a "service level" operation, which sort of implies to me "always running", which seems like a bit of a waste, but treating it as a sort of service like you're saying, while it is running, where it provides an API that other apps can call into it with, like to query information (although that could, I guess, be done with the database stuff that is used now, if someone wanted to explore that farther) about things.

                    I'm imagining that once you launch the application, you simply have a floating toolbar, that sits always-on-top maybe directly above the windows taskbar, or on one of the other screen edges, and provides buttons to access the various things - like a button that opens the current "default" editor view, the 2x2 split, and a content browser button, actor browser button, all the various tabs that are currently in the browser thingee, etc. Sort of a GIMP-style, but without nearly as much junk in the default setup

                    Comment


                      #11
                      Well thats the idea is that UE will run as its own frontend instead of requiring numerous different applications which load the same resources in one way or another.

                      Ofcoarse being a service means its also optional to run, Im not going to sit here and say everyone should have it running all the time since you can just set the service to manual and be done with it. That option itself could be accessible from the engine properties (which is in an ini somewhere).

                      One of the benefits here is we could have frontend access to the engine configuration and it'll detect those changes and restart all sub-systems accordingly just as with a parallel compile.

                      Basically we are discussing UE as being a base for a toolchain, the game is only a minor portion but we dont have to quit the editor to play the game so obviously the game resources are already loaded. The editor resources arnt loaded when running in pure client mode, so that option will still need to exist and will be run by non-developers.

                      Right now the toolchain sits ontop of UnrealEd, which is only a small portion of the Unreal Engine as a whole, it does even give people a misconception about the Engine itself. One example I might use is the advanced graphics setting button in the original Unreal which actually opened up an UnrealEd property window so they are intertwined. I believe seperating the level editing portion of the editor (so it can get alittle bit more enhancements itself) is a smart move, this will open the door to assets not being directly linked to maps such as in kismets case.

                      As a hypothectical if kismet could use uscript objects created/compiled on the fly it means theres a possibility for kismet to have a sub-editor of its own for creating objects using a similar flow but hooking through the native syntax of unrealscript (which it does at some level already).

                      Comment


                        #12
                        What numerous applications?

                        Comment


                          #13
                          I could see some reason to work in streamlining the engine (like only loading what's needed), but to be honest I don't think it usually pulls enough resources for it to really be noticeable. But that would cause a lot more load times.

                          Comment


                            #14
                            Originally posted by ambershee View Post
                            What numerous applications?
                            Well if I have my programming editor open its loading UC files isnt it, so thats still Unreal Engine resources in one form or another. Theres the frontend, the editor, the game and the commandline all similar but theres no direct access through a front end.

                            The point here is I can hit content editor and it would load that, it wouldnt load unrealed in its entirety, same with any sub-editor, including any aforementioned IDE's.

                            Im sorry if you dont understand what Im trying to get at but in my eyes unrealed is by no means a cohesive application and is made up of small parts which happen to work together, sometimes poorly.

                            The goal of this thread is to discuss the Unreal Engine toolchain and its amalgamation to enhance workflow, not for me to explain each little comment I happen to make. Im more then willing to discuss this and am open to any reasonable views apart from my own. Being against something for the sake of it is your perogative but I would like to hear thoughts on the matter instead of doing all the talking.

                            As an example I could say something about Photoshop and its filter view that sits ontop just like unrealed windows do, I dont happen to be a fan of that either and would much prefer see the interaction in the default viewport. We arnt however discussing Photoshop or 3DSmax (both of which can be run from the commandline and run scripts).

                            Comment


                              #15
                              You're aware that the content browser needs the renderer in order to function? That's the vast bulk of the Unreal executable needing to be loaded right there. Same with all of the internal editors that constitute UnrealEd.

                              I don't think there's any part of the toolchain that benefits from being seperate, except maybe the script compiler and the existing seperate tools.

                              Comment

                              Working...
                              X