I don’t think that’s a limitation for adding support for other renderers, it doesn’t have to be so tightly integrated into the engine since it’s just rendering the lighting rather than an actual in-game renderer.
i support you …
There’s more to it than just lightmaps. There are light probes, cubemaps and other miscellaneous data.
Reflection maps would be created in the engine renderer, not the lighting renderer (lightmass) Light probes might work the same way
Sorry guys but I really don’t get it. You are comparing some apples with bananas. I won’t say light mass is perfect but it does a good job for what it is intended to do. It looks like a misunderstanding of technology. You can’t go and use an engine that is made for real time rendering while moving around in a scene, creating an image in a fraction of a second, and expect the same results as an engine which is made to render one still image in minutes or hours.
Once vray or corona are able to render in real time I will support your demands. But until then just try to get your light maps right and it will be reasonably fine. It will never look like a vray or corona rendered image. Something that is done with unlimited time and unlimited resources (memory and geometry detail).
Look at it that way: with vray or corona you try to take a photograph. In unreal you are more like a painter. You can do realistic paintings but they will always be paintings and sometimes you need to hide a few things. If your painting is consistent then the viewer will believe it. If there are spots of super high detail next to something very undefined then your painting won’t work. I know it can be frustrating to not get the result you expect. But if you understand what unreal 4 can do and what it cannot do then you can get some really amazing results.
But what octane is giving unity and ue4 is a progressive renderer to replace lightmass to bake lightmaps. If you’ve used vray before they introduced their progressive renderer you’d know how big of a deal it was. I think it came with version 3.0. Corona is a progressive render too. Lightmaps generation with lightmass is too unpredictable and you cannot have a decent preview (for archviz, that means we won’t have to make 56 test bakes until we like what we see). Of course if you are making a game it’s not the same requirements. Octane is not going to be a new real-time renderer. It will be a new offline renderer within the game editor. It’s a new complimentary tool. It could’ve been just an offline renderer to make nicer stills, panos, etc. but on top of that it will be able to bake lightmaps.
Lightmass was intended for gaming and it’s enough for that purpose. But like it or not ue4 is starting to get traction in other industries and they have different needs 
It’s a matter of time until a better offline renderer/baking system will be implemented.
This is what progressive lightmap baking looks like, tell me it’s not better than lightmass where you can sit there for hours and have no clue what your shadows will look like once done :
This is from 2014.
***Read this post on reddit, Otoy confirm ue4 path tracer is in development. This is what it looks like. Instant High quality preview before baking high quality lightmaps.
https://www.reddit.com/r/oculus/comments/5au90v/otoys_jules_urbach_on_octanerender_unity/
There are quite many open code based rendering systems where Epic can get ideas and even perhaps use code with heavy modifications depending of what oss licence they have.
I think you miss the point. I´m primarily talking about using those renderers to replace the way lightmaps are created. In the end you will still just get a lightmap that is used exactly as they are used now. The only difference, they are created with a much better method that is way faster, more precise, supports distributed rendering in a way to use 100% of all available power at all the time (unlike lightmass) and enables lighting possibilites that are not to achive with lightmass at the moment. Regarding your comparision of a photo and a painting. One of the reasons I choose Vray as my primary renderer is because it also offers the possibility to render stuff in a not completely physical correct way. For example you can tell a light to affect only certain objects, a mirror to reflect only certain objects or a shader to use different materials for reflections or refractions. Just to name a few examples. Having those abilities are very important when you´re into arch or product viz. If a customer wants a certain effect you can´t tell him, oh well sorry this doesn´t work as it wouldn´t be physically correct. A modern renderer offers you way more abilites to precisely control the look of your scene than lightmass does at the moment. No matter if you want a photo or a “painting” you can do all of this with a modern renderer. You´re stating those Vray or Corona Images are done with unlimited time and unlimited geometric detail. This is pretty much wrong. First of all. You can get decent images that are close in quality with lightmass, no doubt. But it takes ages to render and because of that they are a pain to debug when you have lightleaks or blotches. Actually corona or vray or whatever will safe you a lot of time when rendering lightmaps. If it doesn´t matter for you that a final lightmap calculation takes hours or maybe even days to calculate, well… that´s good for you. But if you want to bring the unreal engine into new industries where you have customers that demand a certain quality to be produced in a certain amount of time, than lightmass is simply not enough. You could get 1000CPUs and lightmap still would not be a single second faster because of the way it handles distributed rendering. By the way lighting quality is not defined by the geometric detail of a scene.
Implementing a realtime pathtracer as it was brought up in this thread and shown by OTOY probabely wouldn´t make much sense for lightmake generation. It would be a nice to have for a quick lighting preview but that´s it. When baking lightmaps you would probabely want a production mode renderer where you set a certain quality with a variable amount of time (wich does not exclude pathtracing methods) rather than a progressive renderer where you would set a fixed amount of rendertime but in return get a variable quality per lightmap. But well I think that´s probabely how OTOY will handle lightmap creation anyway. Also Brigade from OTOY way allready hyped 2 or 3 years back. They don´t have the best reputation in the community. Hopefully they deliver this time.
Using progressive rendering in an application or game as the final GI solution is probabely the future, but a far distant future. As we can see in the example the noise is still way to heavy to get decent results. It will take quite some generations of GPUs until you get 30 noiseless images per second in an indoor scenario without having a nuclear plant and supercomputer in your basement. As we can see for the moment it still takes 1-2 seconds to get a half decent image in a bad resolution. I mean that´s allready fantastic but simply not enough for realtime use. 1-2 seconds means we need hardware that is like 100 or 200 times faster than now. I´ve tested a lot of progressive renderers that are out there. Non is magically faster than the other. They all use roughly the same allgorithms and all have roughly the same speed. It´s just a matter of hardware you have underneath. OTOY afaik uses their GPU render cloud for some of their demos.
But as long as realtime pathtracing is in the distant future I´m more worried about lightmaps
No matter if you´re doing lightmap baking for games or archviz or whatever. After all it would mean you get a better lighting quality in a shorter time while it doesn´t cost a single millisecond more rendertime in the final applications.
Until some method of realtime GI magically appears, that offers the same quality lightmapping is the best solution and it probabely will be for quite some time. Non of the things I have seen really convinced me that a realtime gi of that quality is is just about to happen. Well, I still wonder why no one ever implemented imperfect shadow mapping into an engine. This was the best realtime GI I have ever seen. Strange, but there might reasons I´m not aware of.
Yeah, this is just about lightmaps, which is functionally the same as if you bake your lighting using Render to Texture with Vray
The issue is Lightmass has some problems with how it functions and the results it gets, the main issue is how each object gets handled on a single thread, which makes it slow and causes visual issues where objects don’t match lighting.
Ok, I think I understand what you are saying. And obviously there are some problems with lightmass. Here is an example. I did try to replicate your scene to see if I get a better result. Well - it didn’t work. I think because it is an extreme case, at least for light mass. You have no light other then the sun light and you have only a very thin wall between a totally dark and a pretty good lit spot. So there is some pretty bad light bleeding.
I used standard settings with a stationary sun light with 3 bounces and a skylight . It doesn’t look a lot worse than your version other than the bad light bleeding but it took less than a minute to render. Light map sizes are 256 for the floor and 512 for the wall/ceiling mesh. Pumping up the settings doesn’t seem to make a difference so I usually leave it close to the default settings. You only end up with ridiculous render times if you change some of the default settings too much without any real benefit from it.
The light bleeding is a huge problem in this image. But only a theoretical one because we would definitely put some lights in this nook. Then the light bleeding disappears. My theory is that lightmass tries to blend the totally dark and the bright spots so the transition isn’t harsh. Because it doesn’t change when I change the UV layout of the light map or the resolution.
So I put some lights in the nook and applied a few simple materials. It still only takes a minute to render on my 4 year old i7 PC.
This isn’t perfect but I think it isn’t too bad either as long as you don’t compare it to traditional vray renders. Part of the problem is that traditional vray renders are often unrealistically clean. If I look at my ceiling in my flat at night, I can seeall kind of weird shades of grey.
It is like a photoshoped woman in a fashion magazine, no one looks like that. I wish we could train our clients to accept little imperfections for the greater picture.
I am not saying that light mass shouldn’t be better. I think they are trying but they have to balance a lot of things and currently still image isn’t on the top of their list. I personally try to work around the problems. I learned that from games where the process seems to be a bit smarter. You don’t set the angle of the image in stone. If it doesn’t look that great from this angle why not moving it a bit to the side. Or we could put a picture on the wall to distract from the little imperfection. I wish we all had better clients.
This looks good but we have to wait and see if it really is better or if it just has other problems. Also we need to see how the renderer works once you put 300.000 vert vray assets in the scene ;). Does it support real time at all? It’s good to have an instant preview but do be honest I think I would go mental if I had to work with this feature.
I don’t agree that light mass is very slow. It is only slow if you change certain settings. A preview build takes a lot less time and it will give you a good impression of what the production render will be.
I think “realtime GI solutions” is not main subject. We have to talk about new renderer. I totally agree with suggestions. Lightmass calculation and quality, swarm distribution methods look old fashioned and time consuming. I tested network rendering for swarm and it is really useless. Cores does not work together. You can not use your cores efficiently . As said before that one core has a job and another cores wait in vain. Unreal team must write new renderer in short term, maybe in UE5.
Looks like Otoy will beat epic at this race…
I agree that it’s frustrating to have to wait sometimes double the entire bake time for one or two threads to finish up, would be great to have them all work at 100% together to get the job done as fast as possible!
Redshift for Unreal Would be awezome.
I don’t think you understood my post about VRay. It has opened it’s SDK. So anyone actually can buy it and make a plugin for lightbaking. You don’t need realtime GI for ArchViz. You need good reliable baking solution. Which VRay is.
As someone who is developing GPULightmass, I’d like to point out that most of Lightmass’s light leaking, blur shadows are not caused by Photon Mapping, but Irradiance Caching. Try to turn off bAllowIrradianceCaching (this would make Lightmass even slower) and you will get sharp shadows, along with a lot of noise. 