Ok cool Rafareis!
nice result
Thanks.
In my installation folder, it’s named BaseLightmass.ini.old.ver
I copied its content to my “project folder\Config” and renamed it to BaseLightmass.ini. I still see splotches everywhere. How do i know if it’s taking effect? should i reopen the project or is rebuilding the lighting enough? (i already tried both)
I have UE 4.7.6 and 4.8.3 installed
There are lots of threads on the location of baselightmass.ini, you shouldn’t have to move its location.
https://forums.unrealengine.com/showthread.php?55604-Noob-question-about-BaseLightmass-ini
I tried to bake the whole salk institute with the settings in my previous test. After 11 hours it was still at 11%. And that’s with 2 core i7 
Light Leaks
Hi friends,
So until now we had two different situations that required different approach to tackle them -
Situation 1 - Using only skylight with HDRI as cube map to lit the interiors
We face problem of light splotches on the walls which are not coming in direct of first bounce. But fortunately community members were able to provide easy solution to this problem through changing some values in Baselightmass.ini.
Solution - Increasing NumHemisphereSamples value to 512 () or NumHemisphereSamplesScale value to 128 (Koola) will get you the clean GI results without changing anything in Baselightmass.ini (Don't change both values together, they are the same values just on different location, Use either one of them but not both).
Lightmass Settings -
Static lighting scale = .1
Num indirect lighting bounces = 100
indirect lighting quality = 10
Indirect lighting smoothness = 1
Situation 2 - Using Point, Spot or mesh lights in conjunction with Skylight.
We face infamous problem of light leaks, Unfortunately there is no concrete solution provided as of yet.
Solution - Not provided as of now.
I have already lost three commercial projects due to problem of light leaks, because clients are referring to Unreal Paris for quality and to achieve that I have to lower the “Static Lighting Level Scale” between .1 to .4 and on those values putting spot light or point light ruins the whole scene. I have managed to put out some decent work form Unreal lately by playing with BaseLightmass.ini, but still there is so much to learn.
@ - Critically need solution to problem of light leaks. @ and @Koola already have overcome this in there scenes (So solution is already there somewhere in BaseLightmass.ini, UV workflow or anything else).
@ - You are free to investigate problems on developer level or implementing new things, but meanwhile Kindly tell us the workflow to remove these light leaks.
Meanwhile I have also found something very interesting while experimenting with BaseLightmass.ini file (On same uploaded scene) -
Static lighting scale = .1
Num indirect lighting bounces = 100
indirect lighting quality = 4
Indirect lighting smoothness = 1
Values Changed in Baselightmass.ini
IndirectPhotonEmitConeAngle = 2
NumHemisphereSamples = 512
Lightmass Resolution of walls - 256
Lighgtmass Resolution Roof and Floor = 1024
On Medium Preset
Render Time = 19 Mins on single i7-4930K Overclocked at 4.6 GHz
Here are the results -
&stc=1 &stc=1 &stc=1Same scene Rendered without changing [COLOR=#800080]IndirectPhotonEmitConeAngle = 2 (Keeping it on default value i.e 30), all other settings are same ([COLOR=#800080]Render Time = 19 Mins).
&stc=1 &stc=1 &stc=1I am loosing some indirect lighting while using [COLOR=#800080]IndirectPhotonEmitConeAngle = 2, other then that I don’t see any mojor differnce. May be I am 100 % wrong on this approach, but who knows.
- Don’t know what I am doing here, is this even a solution?
[/COLOR][/COLOR]
[/COLOR]
Interesting tests. Right now we may know the settings, but these are very simple scenes. When you have a big scene (my salk institute has about 2000 meshes/lightmaps) it takes FOREVER to build and that’s with 2 core i7. Think i’m going to have to let my pc run for the whole week-end lol.
My scene Unreal take on classic has 2300 meshes with all walls, roof and floor @ 1024 Resolution with other meshes at 256 resolution minimum. It took 22 hours on 2 x i7 4930K 32 GB RAM each. When you think what you are getting in the end - Unlimited camera angles for still images and animation, 22 Hours seems like a breeze.
You have to experiment with different values, and avoid Indirect Lighting Quality = 10 (For me it always worked between 4 - 6).
That’s what we are targeting here - Balance between quality and rendering time.
**** that’s a lot, but during those 22 hours you cannot work on anything else, unless you have more pc hehe!!!
I boosted up a lot indirect lighting and general “feel” of the scene using the post process volume all over the place, and the results are very nice ( and tweakable in realtime which is really handy, once you solved the problem of the light leaks.
I would rather use tricks rather then have a 100% Vrayish as possible results which takes 50hours to render.
I would also like to include a of the RealtimeVR:Biotic which explain the lighting process which they use…nothing out of space, but this could help ![]()
I am sure that or someone else will come up with a solution in the near future for more “optimized settings” so we can get decent quality with decent build times. I guess that these boosted up settings like .15 static scale that increases build time a lot also increases some calculations(time) which does not really affect a noticeable difference. In other words , we are probably wasting a lot of building time, and we might not even know it. But then again I might be wrong.
However if this is the way how building times we be I will probably have to start looking into building a home render farm, something like has. Seems kinda expensive but it would probably worth it. I am curious if with that horsepower it took him 40-50 mins to build that apartment how long would it take with a single i7-4790k.
I have a Dual-Xeon 2670 v3. 32gb RAM. My latest work, apartment, tooks about 20-25min to render. But the scene Riviera House tooks 5 hours. Maybe in this site PassMark Intel vs AMD CPU Benchmarks - High End you can compare your CPU speed with mine.
The parameter NumHemisphereSamplesScale it’s not enough to avoid lighting problems. You have to play with PhotonSearchRadius in some cases. You can speed up your rendering time with a good balance of these two parameters.
As I said, I’m going to publish a pratical guide for this process in the next few days.
Thanks, I’ve been over that list last night comparing performance and prices. Before actually taking a decision to buy that I would make a new topic and get more details on what would be best option for UE4’s lightmass. Does the number of cores have better impact then Ghz, would it be faster with 10 older CPU’s or 2 new ones etc. ( that kind of stuff). From what I know so far RAM has no impact on speed, you just need enough to load all that data.
But before that I want to see what comes out of this topic, conclusions on how to tackle lightmass in different environments, build time optimizations etc.
Muchos gracias for taking the time on the upcoming guide!
thanks rafareis for sharing,this topic is getting more and more intresting
If we could make the swarm agent able to use cloud computing (amazon , etc) that could solve alot of problems. It would be very effective because we don’t need to render 36 000 HQ frames that would cost so much money (e.g rendering a movie) We just need a quick boost in computing, could take just a couple hours. what takes 22+ hours on our pc could be done very fast when you have a huge farm full of xeons. We wouldn’t even need to optimize/change lightmass. Let’s just crank everything up and spend a couple $ to get a quick build. Time is money!
This must be possible because…
-We will need to use static lighting for a while because of VR. Forget dynamic G.I
-We will need to be able to produce large scale projects to be competitive on this market. Large scale project with the same quality as small interiors.
I don’t want to be negative but sometimes, well a lot of the time, I don’t think Unreal is going to be the solution for Archviz long term unless they can get away from lightmaps. In a real world scenario it’s just too much labor for the fees. I kind of think I’m wasting my time with the software. Just my gut level thoughts.
Currently the Archviz “Queen” is Lumion…is so easy to use that is almost embarrassing and righfully so, because it does what it does and the results are very very nice…you also have a viewer which can be sent to the customer and he’ll be able to check everything by themself which is a pretty good solution.
No VR for now but I think they’ll add this feature in the near future.
UE4 have stunning features and can be adapted to do anything, but if far from being a 100% bullet proof solution for ArchViz, mainly because of the time it takes for the lighting, which is the critical point 99% of the time.
There are realtime solutions for GI but far away from being usable on a daily base and especially to show to the customer most of the time, and of course it takes a beast of a rig to run something like that…
I wonder if with Enlighten the realtime GI is something which is well implemented or is something which is still in early stages…
I guess it really depends on the project. By too many labor do you mean unwrapping for lightmap uvs?
For my projects I tend to just use automatic generated lightmap uvs which work really well about 90% of the time.
After that it’s just a matter of making the materials (of which you could make libraries for future projects), making a light setup and doing some interactivity (which you can both store in a template).
But maybe we should discuss this on another topic, because it’s getting a bit offtopic and we should save this thread for awesome lightmass explanation ![]()
Please guys don’t let this thread go off topic.
If you see my previous post. I think #66 on the previous pages there is nothing stopping you from doing cloud rendering now with lightmass. Of course you have to know how to set on the virtual machines and install the required programs much like you would if you were setting on a LAN render farm. There is also of course a bit of networking involved with setting up VPNs etc so all the remote machines can see it other, or at least the coordinator swarm machine. Only thing is as you can see from my screenshot the swarm machines(Cloudswarm1-4) actually ended up doing very little work compared to the local machines. It does work better for bigger scenes but we are still seeing that the cloud computers end up finishing their workload very quickly compared to our “slower” local machines here. It would be really nice if they could re-engage and get some of the remaining work from the machines that are still processing. Essentially auto-balancing.
In summary it still seems you may be better off with a very high CPU density in one to few machines similar to dual xeon setup. Still testing though… Will post more results soon.





