Download

Plugin tutorials

I would love to see a plugin tutorial series, where it explains everything from creation to usage in a blueprint etc…

for example, i’d like to create a plugin that generates custom geometry, an icosahedron for example, and then the ability to use and modify that in a blueprint. right now i see the custom mesh component that James made, but understanding what and where to use it is the problem.

i’d ideally like to be able to create subsystems for team members or for resale on the marketplace.

The first draft will be out this weekend. =)

My plugin tutorial covers how to configure and setup a new plugin. The details on creating new geometry and or entities is not exactly going to be covered, as it is not important to the Plugin tutorial itself. If you would like, Rama has a plugin that modifies the editor engine to allow vertex snapping that you may want to look at for details on the implementation of his specific tool.

that’s awesome! :wink:

the reason i’m curious about the geometry is that the plugin itself would obviously be responsible for generation etc, but i’m confused as to how to handle LOD. would i do that in the plugin itself, or is it handled either via tessellation shaders or is there a generic CPU CDLOD/ROAM/chunked implementation already in there? so obviously, i’d need to know what virts or callbacks etc i’ll need to implement in the plugin. or do i have that all wrong?

The name plugin is actually a misnomer, conceptually. My tutorial will be covering a bit of this, but the broad brush strokes come down to a plugin being a part that is not depended upon by any modules and a module has counter dependencies. What you are talking about would actually be a plugin, if you were to do it using generation in code, but you can make it into a content module too, to provide the meshes or whatever you need to in that form, at which time you would be able to handle LOD in the standard fashion in the editor. I am not sure i know what you mean about creating new geometry though, and that’s where the important details lie. You shouldn’t really be using the editor for modeling, and if you are making BSP, that shouldn’t really have LOD on the BSP itself, but maybe the texture may change, which is still handled elsewhere.

It could be that you are talking about procedural generation, which I am also interested in, but that is in its infancy in UE4 and ill go ahead and volunteer you to be the new head of procedural content within UE4 if that is the case.

Either way, I will bookmark this thread and post a link to my tutorial once it is up, and monitor your progress if you update here. =)

Cheers

excellent :wink:

i recently came over (as did others i think) from unity. i was able to procedurally create planetary terrain using noise etc, including handling the LOD, but unity currently suffers from the following issues for me:

  • source code :wink:
  • double precision, required to reduce z-fighting and transform postiioning, thus limiting the sandbox to around 100k units before things get really squirrelly. granted, there are some hacks i can use to get around this, but to be honest, i’d rather not.
  • multi-threading. while i have everything i described working, it doesn’t work well because of the nature of their threading. this is supposed to change in 5, but for right now, it’s almost unworkable due to either stuttering during object creation funneled down to only the main thread, or coroutined which introduces lag

as far as i can tell, UE4 (and since i have source) i can address all of these issues. just not sure how to get it into the editor properly in a way that, if it’s successful, i can submit the subsystem to the UE4 marketplace. or make it open to the community. who knows. first i have to be able to find my entry points etc :wink:

think along the lines of Proland/Infinity/Outerra for UE4 and what i’d need to do to implement it. hehe it probably covers several tutorial series, but the main one for me, is how to get the hooks in place :wink:

EDIT: btw, if there’s anything i can help with, let me know

hey bob :wink:

were you successful?

I have been successful in creating and documenting the flow for creating a plugin. The link is in my signature.

The tutorial is not fully expanded, namely in the module/stand alone plugin sections, but the gist of how to organize a plugin is there and should, at the very least, get you going.

=)

I will do my best to finish those two sections this week, but i have a sick baby and may be in and out, depending on temperatures, labs and/or screaming.

excellent, thank you bob :wink:

Hi Bob,

Thank you for the contribution to the Wiki. You can see that I’ve had Adam make it the Featured Tutorial this week. Keep up the good work!

I would also like a plugin tutorial that allow us to create and edit objects inside the editor.

Tutorials, by nature, are not likely to be able to address everyones needs. If you would like to make a plugin to modify something interesting you are free to dive into that and document the process. Each tutorial should be general enough to be used on multiple projects, contexts and by multiple people. I hope to be able to provide a few plugins to extend the platform, but will not likely write tutorials for them all. If you would like to modify objects in the world you can, and probably should, read through Rama’s plugin - because it provides a very interesting set of functionality to the editor that we can all probably use.

Best of luck to you, good sir. I hope to see a plugin release page for one of your own plugins soon!

@Alexander - Thanks a bunch. I plan to. =)

I guess I didn’t explain well enough. A plugin tutorial that would allow us to create and edit objects inside the editor… Well, this would be something like a “Hello world” tutorial. Right now I don’t have a clue about where to start.

I completely understand what you mean.

The best place to start is to take a dive into the engine and look around. If the need is there and specific enough, tutorials will be made - keep in mind I’m not the only one around reading these posts and writing tutorials. The main perk to having engine access is that you can now literally step through the tools, including the editor, to see what is being instantiated, and how it is being used. You can add more types of brush shapes, or generate meshes procedurally if you just dive in and muck about. The first thing you have to be willing to do with an engine the size of UE4 (that also happens to be in a repository) is break things. Just dive in with a minor goal in mind. Before you know it you will have solved a problem you didn’t even know you had.

Hey Bob? while i understand we all have the source, for me personally i’d like to take a small liberty on points of interest if that’s ok? i of course, don’t intend this to be done by you solely, and i’ll help where i can, but it helps me to get a better understanding if we start from mile high, for example:

  • Introduction

  • Concepts

[INDENT][LIST]

  • What is a plugin and what does it mean to UE4?

  • What kinds of things can you do with a plugin?

  • Can i use shaders for a plugin and how does that work? Anything extra that i need to do?

  • Marketplace. Can i sell it?

  • What it’s for

  • Intended audience

  • Basic rules for determining usage

  • What it’s not for

  • Anything that excludes usage by nature, type, license etc

[/INDENT]
Pipeline and Architecture

  • Rendering Overview
    [INDENT]

  • Short discussion on the current rendering pipeline. Preferrably with a simple visio type flowgraph

  • The Plugin and Rendering

  • Short discussion on the rendering pipeline and how, when and where it fits into the main rendering pipeline. Preferrably with a simple visio type flowchart

[/INDENT]
Development

  • Types of Plugins
    [INDENT]

  • are there different types? and if so, what are they? are there any reasons or exclusivities to prefer one over the other?

  • Performance considerations?

  • Dependencies

  • Are there any dependencies that we need to carry required by the engine?

  • Dependent plugins?

  • Custom plugin dependencies

  • Best Practices and Standards

  • Are there any?

  • Static or dynamic linking?

  • Attribute Decorations

  • What kinds of attribute decorations are there and which ones do i need?

  • Code, Where and How

  • Creation and where to build it

  • What do i have access to?

  • What functionality do i want to expose and how?

[/INDENT]
Debugging and Testing

  • Overview
  • Things to watch out for, Gotchas

Deployment

  • Targets. Editor, Runtime or Both

Usage

  • You’ve built a Plugin, now what?
    [INDENT]

  • This one is a biggy. So where and how, based on type of plugin, do i tell the artists to find and use it?

  • Can they be used in a blueprint?

[/INDENT]
[/LIST]

some of this stuff might be redundant, however for me and other folks just acclimating themselves with the engine, this would go pretty far imo. this is by no means a complete list, just some suggestions.

being that plugins are meant to be the main extensibility to custom, missing etc functionality, i would think that this would be a primary concern for all of us.

Excellent suggestions Marionette. Covering those will be extremely helpful. I’ll forward this to our C++ expert here (Rama aka evernewjoy). :slight_smile:

here’s another question that i just thought about that could go into the coding section:

do i need the complete source to make a plugin or is/will there be an ‘SDK’ or headers etc and which headers?

i’d love to be able to help out an answer more of these, but i’m just not getting the full picture from the code yet, nor the complete intention/implementation of things to come.

EDIT: also, is plugin functionality to be added from the unreal guys, or is it only to be a stub implementation and the community will be responsible for fleshing it out? is there a roadmap somewhere?

I think most of this was addressed in the tutorial, but i will go through it and give you some one off answers if that is how you wish to consume it.

  • Introduction

  • Concepts[INDENT]

[LIST]

  • What is a plugin and what does it mean to UE4?
    [LIST]

  • A plugin provides the ability to extend the engine. I really cant harp on this enough - the entire UE4 platform can be thought of as a system of modules, and by changing a class reference in the config files you can now be running your own Editor class, as Rama has done, or adding V8 to support scripting in UE4 using JavaScript.

  • What kinds of things can you do with a plugin?

  • You can extend it to include functionality that you feel is missing, such as supporting the blender model format, or a language run time, create a new set of tools that your games can build off of, or (eventually) package up a set of assets that you wish to use across multiple games. There are also people talking about releasing additional Blueprint nodes via plugins.

  • Can i use shaders for a plugin and how does that work? Anything extra that i need to do?

  • A plugin is really just an encapsulated module, and you can do with it anything you can do in a standard game module, including adding maps, shaders, or any other kind of content (eventually). As noted in the tutorial, the content plugin is not yet supported.

  • Marketplace. Can i sell it?

  • Yes.

What it’s for

  • Intended audience

  • Any developer interested in the above that has the technical wit to stick content into the content directory, and/or to add a set of files as described in the tutorial and compile them out. The tutorial suggests that you have a more than cursory understanding of C++, primarily because you should be able to understand that you are working with imported libraries the whole way along. Building a module/stand alone plugin is basically building a DLL to be imported into your game at a later time.

  • Basic rules for determining usage

  • As above, there are three types of plugins, i suggest you read about

What it’s not for

  • Anything that excludes usage by nature, type, license etc

  • You will, of course, be dealing with whatever license details that Epic puts upon these plugins, but you may in the near future be able to include an EULA and or a License of your choosing if they allow it. You will not likely be able to GPL it, or LGPL it unless your plugin is strictly to be included as a DLL.

[/LIST]
[/INDENT]

Pipeline and Architecture

  • Rendering Overview[INDENT]

  • Short discussion on the current rendering pipeline. Preferrably with a simple visio type flowgraph

[LIST]

  • You will need to discuss this with an engine dev or to read the API/step through the code. There is very little about the pipeline or architecture that is simple.

The Plugin and Rendering

  • Short discussion on the rendering pipeline and how, when and where it fits into the main rendering pipeline. Preferrably with a simple visio type flowchart

  • Your plugin does not exactly fit into the rendering pipeline. It is a module, and is treated like all other modules in the game. You can extend or modify the rendering pipeline using a plugin, but you would be sticking yourself into the pipeline at a determined spot.

[/LIST]
[/INDENT]

Development

  • Types of Plugins[INDENT]

  • are there different types? and if so, what are they? are there any reasons or exclusivities to prefer one over the other?

[LIST]

  • This is covered in the third section of the tutorial. There are three, Content - having content only, StandAlone - having code to extend the engine but no public API, Module - having code and an exposed public API. You can have one, or any permutation of the three in your code. In fact, you may have many of each, hence the term Bundle being used instead of Plugin.

  • Performance considerations?

  • With all things under the UE4 development pipeline you should test your plugins before you get them into the wild. Performance in a bundle is just as important as it is in a standard game module, and you are ultimately going to have your code run in the same context as a regular game module. There is no reason to single out modules or stand alone plugins for performance issues.

Dependencies

  • Are there any dependencies that we need to carry required by the engine?

  • Dependencies are going to rely upon your needs. I think you will likely need Engine and Core, but there is no requirement that they be included - nor is there one on any of your other modules. You declare them in the Build.cs file.

  • Dependent plugins?

  • This is a tricky one. You can have modules be dependencies of each other, in the same way that you declare dependencies for standard game modules, and i addressed this with the non-game module. You have to change its load time to predefault and ensure that your game module is loaded at the default or later time. The issue you will run into with multiple levels of dependencies is that you are not guaranteed an order to be loaded, and as far as I know it could be alphanumeric in nature. Since you are not able to ensure that your plugin is loaded after a dependency, save the different load time entries, you wont be able to do much.

  • There is not really a benefit to a plugin being a dependency, as they have no public API.

  • Custom plugin dependencies

  • I will need for you to be clearer about what you want to accomplish here to be able to address your interest. There is nothing any different between a standard game module and a bundled module, as far as we know. You can include external API, as with my V8 binding, you can extend the editor to provide further capabilities. it is all at your disposal.

Best Practices and Standards

  • Are there any?

  • The best practices are the same as with UE4 coding and asset creation. You can read the coding standards and content creation standards on the official documentation site.

  • Static or dynamic linking?

  • Your choice. I address the implementation differences in the tutorial when talking about the public/private or dynamic lists, but ultimately this is up to you, your imposed license and your goals.

Attribute Decorations

  • What kinds of attribute decorations are there and which ones do i need?

  • Attributes Decorations are not supported in C++11, at least no where near the extent of what is supported in C#. If they were we would not likely need to include the macros initializing our classes and properties, but they provide a similar effect. You can use any of them as you need to achieve your needs.

Code, Where and How

  • Creation and where to build it

  • This is also covered in the tutorial. You will need a project to contain the targets and everything regarding your bundle goes under the plugins directory. You build it in the same way that you do a standard project, generating your VS projects first and then building them in VS or on the command line.

  • What do i have access to?

  • Virtually everything. Using the plugin system, Rama has built out an extended editor that replaces the standard editor with vertex snapping. If you can replace the entire editor… you can replace anything you wish.

  • What functionality do i want to expose and how?

  • I addressed how to expose functionality in the sample in the tutorial. Your interface can have static or member functions that call into the internals of your module. You can expose multiple interfaces, and you can expose no interface if you wish to create a stand alone plugin.

[/LIST]
[/INDENT]
[/LIST]

  • Debugging and Testing

  • Overview

[LIST]

  • This is no different from standard C++ debugging and testing of your game. You can do unit/acceptance testing of your module in an automated fashion, or hand it around (as i did with the v8 plugin) to those that are interested in helping me address issues with usability. You debug in the standard fashion, although you will need to trigger a given event by exposing it to a game module and calling it. You can use the entire suite of tools MS has provided us with.

  • Things to watch out for, Gotchas

  • I took the liberty early on to start putting code gotcha’s up on the wiki. Please do add to them.

Deployment

  • Targets. Editor, Runtime or Both

  • Deployment of a bundle that you want to be used in each of these situations is the same - drop it into the plugins directory. The plugin descriptor actually notifies the runtime or editor about the conditions that you want to have your plugin loaded in. The type parameter is discussed in the tutorial in section 5.1 - Stand Alone Plugin | File Structure

Usage

  • You’ve built a Plugin, now what?[INDENT]

  • This one is a biggy. So where and how, based on type of plugin, do i tell the artists to find and use it?

[LIST]

  • To use a plugin it has to be in your plugins directory. You can zip it up and hand it to them. The usage of your specific implementation is going to depend on the issues you are addressing or abilities you are providing.

  • Can they be used in a blueprint?

  • Yes. Absolutely. You can create new blueprint nodes within a module/stand alone plugin.

[/LIST]
[/INDENT]
[/LIST]

All and all, I understand that you have more questions, but I would strongly suggest that you dive in and look around. It is definitely not for the faint of heart - looking at UE4 in its birthday suit - but you are more than likely going to find a home for yourself as long as you are interested in the subject of extending the platform. Hell, you may be able to create bug fixes and release them as interim fixes until the next update from Epic. There is really a lot of flexibility to the current implementation. Join me on IRC if you have further questions. I will transplant any of these not already addressed in the tutorial to the Talk page of the tutorial for better viewership.

You do not have to have the full engine source code, and in fact probably shouldn’t use it for your plugin, save for reference. There are some oddities that have come up regarding this leading to full engine rebuilds which can be quite frustrating. I exported a new UE4 project and am using that as the test bed for my plugin development. I have the full source that I use for reference.

The plugin functionality has no published roadmap as of now. It is not exactly closed off either, as the git hub repo has the plugin tools included there as well. We can all contribute to them to improve them for the community if we so choose.

hehe no, i meant for some of these might be added/merged etc into the wiki for folks that might miss this thread :wink:

as far as adding functionality, i agree, we have the source, however it’d be nice to know who’s working on what and how we want to implement it, if it is indeed up to us.

and i wasn’t trying to take potshots at the tutorial you made, i was simply thinking what i, and other nubs to the engine, are probably asking :wink:

EDIT:
•Short discussion on the rendering pipeline and how, when and where it fits into the main rendering pipeline. Preferrably with a simple visio type flowchart
•Your plugin does not exactly fit into the rendering pipeline. It is a module, and is treated like all other modules in the game. You can extend or modify the rendering pipeline using a plugin, but you would be sticking yourself into the pipeline at a determined spot.

exactly. do i get a render callback so that i can handle LOD calcs? is this something i need to add or is it already in the works? if so, who do i ask? the UE devs?

i’m not afraid of digging into the source, just trying to get some info/background on it first is all.

the points above are simply things that need to be fleshed out a bit more, was all i was trying to point out. here’s another: once i’m done with a plugin, depending on the type, where does it show up in the editor? that kind of thing. right now, when i try to use the custom mesh component, i can’t add it to a BP, why not?

i wasn’t asking for you to answer each one as a shopping list. for example, the market place. sure we can sell things. any idea how? or licensing? or the plan for such things? there are bits of info all over the forums etc, some are conjecture some aren’t but As you have a wiki going i simply wanted to suggest a few things. even if we don’t know right now, we can use them as a place holder possibly.

shrug.