Octane Lightmapping in Unity takes seconds, not hours

Technically none of these GPU lightmappers can do this. So the only possible solution is per object lightmapping
Octane doesn't support automatic per object lightmapping for all scene models (Batch bake) . Its API classes are internal and no one can make this workflow

 

So how much can you bake, something like 2 or 3 objects can be lightmapped with this?

 

Currently Octane is useless for lightmapping. Only you can bake single object with whole texture color (lightmap + albedo map) manually.

POLM has per object lightmapper feature. I tested it and it works fine in mid-scale scenes

and PLM is always the best choice based on my experiences currently for lightmapping out of the box

 

Cool. I was very impressed with the Progressive Lightmapper baking times and quality. However I found a few versions back in Unity it was causing a memory leak or something. My CPU would go 100% and Unity would constantly freeze and have to be force closed. I stopped using it after this happening all of the time. Has the Progressive Lightmapper had bug fixes or improvements to that issue?

 

POLM doesn't actually do colors, though, right?

The Raycast Lightmapping asset, previously called Lighting in a Bottle, is the only one I know of that does full scenes (and in that you have to redo all your lightmaps fairly manually). It gives a killer result, but is slooow.

 

POLM Currently do GI only for Sky and light sources. For diffuse color's GI i think it needs some more improvements (as its developer said)

I didn't touched Lighting in a Bottle

CPU must be 100 in all CPU renderers. It's normal thing
You need 24gb+ memory for large scene lightmapping.

Also enlighten is faster than PLM in very -low preset without Final Gather and AO (you can use AO it's not too much slow)

 

For 2018.1 there is Progressive Lightmapper Large Scene Support

https://unity3d.com/unity/roadmap

 

Damn. I really miss the days of Beast when I could lightmap a scene and work on other stuff easily while it was doing it's thing. I never had to worry about all CPUs being maxed out and the computer becoming unusable. So much for my 16GB of RAM.

 

Unity never addresses this, but basically the licensing for Beast expired, I'm pretty sure. And it wasn't just Unity being cheap, I don't think; Autodesk put out a competing (that you've probably never heard of) game engine right around the time that Unity 5 came out, and the theory is that they stopping being willing to license any of their Gameware middleware at that time or thereabouts.

It seems like a smart move for Autodesk, in theory, if they wanted to make sure their game engine was keeping all its unique points. However, it's something that is so obscure that I can't imagine it makes sense for them anymore. Instead it pretty much just killed wide use of Beast, in my opinion.

Unity has been very much "Englighten is awesome!" and making no response whatsoever to any criticisms of Autodesk or Beast, which makes me suspect NDA about why the agreement was ceased. Perhaps Autodesk would be willing to license Beast again, now that their platform isn't really taking off and Unity is larger than ever... but Unity themselves would be fools to take that again, since Autodesk in some form already ripped the rug out from under them (I believe).

It's really the only thing that makes sense, because Unity are not idiots. And it would explain why they're working on the PLM, since that's something they can at least control in-house and not get wrecked on again in the future. On their part that's playing the long game, but their install base is large enough they can weather the bad blood in the meantime. But they can't talk about it for practical and possibly legal reasons.

It's also why I see them being so excited about other third party solutions like Octane. The only way I'd see Beast coming back to Unity is as as third party purchased plugin along the lines of any other asset store tool. Unity might make some engine pipeline openings for them, but they wouldn't make it part of the base product. Hopefully Autodesk realizes that there is a lot of money to be made if they took that approach with Unity, and they wouldn't have any sort of messy "devaluation" regarding Unity Free customers getting Beast without Autodesk seeing any money from it, if that was their beef. It's possible that the new licensing model in Unity 5 was the actual fractitious part between the two companies.

Either way, a healthy ecosystem of third-party lightmappers to compete with Enlighten and PLM is hopefully in our future. Like most other parts of the production pipeline, it's becoming more and more modular and piecemeal, rather than one monolithic piece of software where you have no choices. I'd gladly shell out for Beast or Octane, depending on which performs better and gives a better result for my purposes. It's an absolute no-brainer.

 

Yeah I think the Progressive Lightmapper was supposed to be both the Enlighten and Beast alternative. A more efficient and faster, less complicated lightmapping solution for those that didn't want to fiddle with realistic GI solutions. Unfortunately I can't use something that uses my entire CPU and consumes the entire machine causing Unity to completely freeze and have to be force closed every time I use it. That's not efficient, that's not user friendly. It didn't always behave that way, but when I try to use it now on any decent sized environment it does.

 

Right -- I use Enlighten pretty much exclusively because the PLM is just a slower and messier approach for me most of the time. I'm on a 6th-gen i7 and 32GB RAM and 6GB 1070, this shouldn't be a problem.

 

Beast and Turtle was for last gen games. Because had very low GI quality (falloff - Distance passed by GI) compare to current renderers (specially indirect shadows)
So beast was unusable for interior lighting. For mobile lightmapping it was good enough

 

I don't know enough to speak intelligently on that subject.

 

Because here is octane's thread, i uploaded comparisons (PLM vs Enlighten) in here:
https://forum.unity.com/threads/vra...s-arnold-in-lightmapping.505099/#post-3314750

 

Yeah, I didn't mean to completely derail from Octane's stuff. To be frank I really hope Octane blows this all out of the water and I can throw money at them and we're all happy.

 

Yeah I think that's where my love for it came from, being primarily a mobile developer for a long time.

 

Mobile game developer should be stay on Unity 4 . It's very faster and easier to develop mobile games. Most successful games has been made by unity 4 without upgrading to 5 (Real Drift, Traffic Rider ...)

Unity 5 needs an High End system to be comparable with Unity 4 in lightmapping with higher quality for non-game purposes (ArchViz etc)

Unity 4 shader programming is simpler than 5 for mobile.

My taste:
Ryzen 7
32 GB memory
100GB SSD for GI Cache
PLM and Enlighten

Continue the discussion here:
https://forum.unity.com/threads/vray-vs-plm-vs-octane-vs-polm-vs-arnold-in-lightmapping.505099

 

Hmm, so you're only 30% faster than me in terms of available CPU, according to this: http://cpu.userbenchmark.com/Compare/Intel-Core-i7-6700HQ-vs-AMD-Ryzen-7-1700/m34954vs3917

But your bake times are a lot better. I have two 1TB SSDs and one slower 2TB 7200RPM drive, and then another that is external and 5GB 7200RPM, but limited by the USB3 bus. I've been throwing my GI cache onto the slower drive 2TB internal drive just to keep it off the drive with my OS and the other drive with my actual project. Am I destroying my baking performance because of that, do you think?

 

But mobile developers often need to keep up with latest mobile OS versions and that often requires keeping somewhat up to date with unity versions. I don't want to exaggerate this point but I couldn't help making it given how old Unity 4 now is.

 

Yes i speaking about lighting and graphics side + Optimization
Unity 4 is not free so it's not usable (needs pro license for lightmapping)

 

My cpu is 4790K
GI cache must be in faster HDD if it's possible

4790K passmark : 11.000
6700HQ : 8000
Ryzen 1700X : 14700

 

Great googly moogly, you aren't kidding. I just moved my GI cache (which is 200GB) from my 7200RPM drive to my fastest SSD.

The first bake after moving the GI cache location, and clearing the GI cache, took 4.6 minutes, which is barely faster than the old time. The old time was 4.9 minutes, and the time savings was from getting the reflection probes and lightmaps saved to disk a bit faster , I think. Not that I moved my actual project, which was on SSD #2...

Then I cleared all the generated lighting for the scene, clear all baked data, but of course the GI cache now had data in it again. Those 4.9 minute times were WITH the GI cache filled. New bake time? 0.6 minutes.

GOOD GRIEF. A 7200RPM drive isn't exactly slow, although by modern standards it's not super fast, either. But if anyone is ever having a really substantial difference in their bake times compared to you, tell them to use an SSD for the GI cache for sure. It's so tempting to put a lot of caches on slower drives since it's a lot of ancillary data.

 

At this point of preview/beta stage yes. Single mesh backing. But is kind of technology preview.

 

Only for large files. Once you start dealing with tiny random accesses that send the drive heads careening all over the place the performance goes down the tubes. An SSD can easily be hundreds of times faster for random accesses but is only typically a few times faster at most for the large stuff. Seek times kill performance for an HDD.

 

Beast is dead. Autodesk discontinued it.

 

Ooh, I hadn't thought of that. Yeah, that makes sense too, then.

More market for Octane, then.

 

well now it is listed as
"LIVE LIGHTMAP BAKING BETA
Experiment with the beta today, more details and sample scenes coming soon"
anyone figured out how to do it?

 

Baking overview. This is so good.

 

OK, 2 things.
Looks fast, so that is cool, scene is not too comples tho.
Not production ready by any means, super manual thing. This cas to be as automated as Beast was. Like you may whant just the light map, a complete map etc but that set as an option and done automatically with no manual camera creation nor manual material creation and texture asignment shown in teh video. still looks like the core is ready and just some automation scripts needed.

 

That's also replacing the entire material in a way that isn't helpful. All of the PBR elements of the material get lost there as they bake to a flat unlit diffuse texture. Yeah it has all the beauty from one viewpoint in there, but it's not going to react to changing light conditions or whatnot at runtime. Not liked baked lighting with enlighten. It will get rid of realtime lighting things like specular highlights and whatnot, too.

 

you can bake only the shadowmaps, or the lighting, you dont need to bake everything and replace the whole texture

 

Awesome! Good to know.