At this point it would be nice to just fix leaderboards (lingering bug) and expose profiles/stats/IAP/DLC to BP :o
Add to the list the GSC/BSP or something, there are huge post about that.
Thanks for responding . As someone new to UE4 development, my biggest workflow hindrance has been setting up scenes properly for Lightmass and the added steps to remove overlapping UVs (not to mention the incessant and lengthy hours of waiting for lighting to build). Clearly Lightmass is very capable but requires an absurd amount of voodoo and then you’re left with static lighting. To me the whole point of getting into realtime graphic engines is the prospect of creating dynamic content. It’s depressing to see these beautiful UE4 environments that are essentially frozen in time.
There are so many clear benefits to incorporating a realtime GI solution and these are a few from my narrow perspective:
- A more fluid realtime workflow without all the baking downtime. The time savings from this alone seems to be the biggest benefit.
- More realistic lighting and objects feel more rooted to their environment. It’s akin to when I’m lighting a set and I can just move lights and they behave and interact as expected.
- Less complicated setups in general so scenes aren’t littered with lighting and reflection gizmos.
- It’s much easier to adapt my Maya/Arnold workflow to a UE4/Realtime GI workflow. You focus more on global sampling multipliers and less on per object optimization.
- It seems scalable. So I can make a scene at a lower quality level and in 5 years after a few generations of GPUs I can simply up the sampling quality in the same project and have a much better result.
- It’s just conceptually easier to work with from the standpoint of trying out UE4 for the first time.
I know it’s not a trivial thing to pull this off but just a few days of playing with the VXGI implementation showed me that it’s painfully close to viable (on a 970 at least). I would be using UE4/VXGI if I could get it functioning in VR (for VIVE).
I think VXGI is a pretty solid outline of what I would need in a dynamic GI solution but heres a short feature list of what I expect/hope from a game engine:
- The usual physical based rays: Diffuse, Specular, Indirect, SSS, AO
- Realistic reflections (even if of the low resolution voxelized variety that can be blurred)
- Dynamic shadows with falloff
- Support of all basic lighting: Area, Point, Spot, Directional, Emissive Shapes
- Basic Refraction
I know some of these things exist in different forms but not in a simple unified and global way. Anyway I’m excited to see where things develop. It seems like Epic are really open to the needs of developers and I anxiously await an optimized, flexible and VR capable realtime GI solution along the lines of the VXGI.
As a side comment, I feel like the current UE4 toolset has started to produce work that has a uniform look. In general it’s a look of AAA quality but i think it’s important for the engine to grow and make it easier for the artists/programmers to impose their personal look-and-feel. Things like dynamic GI can really help add more diversity to the look and feel of UE4 produced content.
Hey ,
That one is a bit off topic from this thread, so I sent over the original thread that you linked to our developer to look into and comment. We’ll see where the discussion currently is, but he’s not outright rejecting it, just double-checking with other developers that it would be safe to implement.
Thanks for these detailed notes and thoughts! These kinds of posts (of which there are many in this thread) help a lot with understanding what is expected out of an “Epic Quality” GI solution. Keep 'em coming 
Alright Well maybe I can contribute a few ideas to the wishlist -
1: A “Far shadow cascades” equivalent GI option. Essentially a super low resolution grid (assuming SVOGI/VXGI/LPV style solution anyway), maybe 1 voxel every 10 meters (or possibly even larger than that), at a configurable distance to either disable it or shrink it down when it’s not needed. Wouldn’t even need to update every frame, the sole point of it would be so there isn’t a visible, hard transition between where the GI starts and ends like LPVs currently have. It’ll be more light leak prone, but if it’s far enough away you’re less likely to notice it.
2: Full compatibility with Lightmass for lights that don’t need to be dynamic if a few extra frames are needed. For example, if there are 100 lights in a scene and only 40 of them are actively moving, ideally the remaining 60 would either be calculated only once by the GI solution or baked down to begin with. Either one will work, but if a light doesn’t need to be updated then it shouldn’t be updated.
3: The ability to disable GI on the light entirely if the artist chooses. This would be more for stylization of course than a realistic representation of light.
4: The ability to independently change light bounce brightness and saturation from the actual light’s saturation/brightness. Again, this is just to give the artist more control over the final result.
5: Prioritization of certain objects or lights to receive higher quality GI than others. This would be mostly useful for cinematics, where you might want the camera to zoom in really close on a character and not care so much about lights off in the distance. Would also be useful for some scenes where certain lights just matter more than others, like maybe you have a night scene and have both moonlight and a flashlight going at once. The moonlight can stand to be a bit inaccurate, but the flashlight would be very apparent if there was any leaking or issues, so the moonlight could stand to be at a lower quality if it’ll save some performance.
6: Light contribution from the skylight, along with making the skylight a bit more dynamic. Right now, changing the cubemap to one already saved on disk -and- recapturing the skylight both cause a hitch (yes, even the solution Zak had on the video tutorial on doing it has a hitch when loading the new cubemap). Currently it seems the best solution is to tint the skylight color when there’s a change needed, which isn’t an ideal solution for all skyboxes.
7: Stealing an idea from VXGI on this one, skylight contribution to specular tracing if the voxels don’t extend out far enough to hit something. It’s better than having no reflections, and if dynamic GI is going to be in the engine then there’s going to be a few projects that opt not to even bake down cubemaps.
8: Manually placeable volumes that GI contribution won’t occur in for any light. Can be used for stylization of particular areas or placed to block light leaking in some situations.
9: Manually placeable volumes that GI contribution won’t occur in for lights on a whitelist. Same idea as number 8, but these would be more for one or two problematic lights rather than everything in the area.
10: The ability to change, per material, what color their GI contribution will be. Sometimes you need red light to bounce off a blue object. Not required by any means to define per material, but there’s nothing wrong with giving the artist more options just in case.
And this one isn’t really specific to GI but something I wish the engine had anyway:
11: The ability to turn off either diffuse contribution or specular contribution for lights (ex: any light in Maya). Sometimes you just need a fill light for a specific area without wanting it to give an extra highlight, and sometimes you want an extra highlight somewhere without the actual light.
I would love to be wrong here but is TAA even capable of doing its job without blurring out all the finer details? That alone makes me not want to use it but a lot is being tied into it being on.
Hi, we are not rejecting this PR. It’s just takes time to get system owners to review this change. Some people here have concerns that origin rebasing feature spreads tendrils across many systems in the engine. And we generally want optional features to have zero impact when it’s not used by the game. That does not mean that we will not integrate it. I think it will end up in upcoming 4.13 release.
Very glad to hear it! Would love to see it in the engine if at all possible. If it can be done, then one of the two hurdles stopping people from making larger scenes are taken care of.
[MENTION=8] [/MENTION], It’s ok to continue the conversations in the related threads. This thread was just meant to be what it’s title says. Since there are many feature requests and threads about them are spread through the forum I wanted to gather them all together along with their related thread link in the OP so it can be one place to help quickly navigate between feature requests/threads/conversations. (For users, who don’t have all of it documented/bookmarked.)
I would like to mention list of feature that might prove very useful. I kindly ask people to support me on these.
1) Add an ability to paint color map on terrain in the editor.
2) Add a feature, similar to landscape grass, but for physical surface id, so that you could control distribution of landscape physical surface types in a shader.
**
3)** Somehow expand functionality of custom material node to support outputting several values. For example, returning float4x4 gets broken down to 4 pins in the editor. This would probably be best material editor change since release.
4) Add an option to change shaders on landscape components depending on the distance from camera to the component.
Dynamic GI is must have Today in almost every game.
When talking about dynamic GI i think you guys should just take a look at cryengines SVOTI, have a look at the quality and performnace. I think a similar system especially so performnat is something that all the dynmaic GI fans here would like to have in UE4.
I don’t see how dynamic GI should be in every game. Paragon has no dynamic GI and looks . So do many other modern games, including recent DOOM.
I would be nice to have everything real-time as it would shorten iteration time (no need to bake lighting), but it’s not necessary.
For me (and many mobile VR folks) having HISMC and foliage to work with lightmaps, or mobile VR optimized distance field shadows is a way more important than dynamic GI. Currently one can build stunning games for PC/consoles using UE4. Not so much for mobile and mobile VR.
If you are going for open world games like Kingdome Come, The Division or Ghost Recon Wild lands you have no choice, ouh yeah you can use just skylight for you game… good luck with that.
I get that the “mobile folks” dont need dynmaic gi but have you maybe thought about that some other people here on the forum would love to have it ? Check the threads and see by your self how big the interest in Dynmaic GI is.
Dynamic GI is a very is a very nice thing… i could even leave with a Probe GI solutions as long we have a “REAL” solution next to lightmaps and only skylight…
A small indie team has higher chances of making (and releasing) a small mobile game or mobile VR game or a small PC/console game without dynamic GI, than making open world game on the scale of Kingdom Come/Division/Ghost Recon.
Large AAA games have enough manpower to implement any dynamic GI into UE4. Out of all AAA games that are being made with UE4, how many use dynamic GI ? I suspect next to none.
I know such thing as wanting to have a feature for the sake of having it. I know for a fact there are people who want more and more features and no matter how many features come, they will never finish and release a single game. I’ve been there myself and I am glad I got out of that dark place.
I have no problem with dynamic GI being on the wishlist. It’s a wishlist after all and it’s a realistic feature that is definitely needed, but in the future. It’s not a priority really.
True. But what about the bigger indie teams?
Even larger AAA teams don’t have the power to compete with Epic in technical and financial issues related to UE4. And even if they step forward and try to do it, at best it will be something like LPVs, AHR etc. which are nothing really useful at all at their current situation.
None. Because there is no good dynamic GI to use at all.
Having no dynamic G.I in a open world/dynamic game is as bad as having no baked lighting in a scene/static environment. But the static lighting has pushed so far while dynamic lighting is still lacking in basic features.
paragon is not open world. doom is a map corridor game.
sure every game doesn’t need DGI, just like how everygame doesn’t need DFAO or Ray traced shadows.
DGI is mostly needed for exterior/open world/dynamic games.
There is no native DGI in ue4 at all (production ready at least), but big studios can use Enlighten. It has its own issues (like no dgi from dynamic objects, proxies etc.), but performance/quality is really good.
Well, not everybody has a @DICE.com or @EA.com and such addresses following their email username. Geomerics do not bother looking at the evaluation requests unless it’s a game from big known company OR the game has already made most of it’s progress. The problem with that is nobody can count on a feature that they might get when they are 70% into the development.