Quote: "means around 700mb+ more space for everything else, byebye 1800mb-limit."
Not exactly, what people never noticed was that Light-mapping memory is dumped after building the light maps as it always has been. When people were crashing on "Creating Lightmaps" it was because WHILE building the lightmaps it would go over the cap before having the chance to dump its memory. I have found a solution to that though.
For example, I tested a map that took 1,000MB to build light maps. This map would crash at "Creating Lightmaps" because while building the light maps it would go over the memory cap, EVEN THOUGH that later on that light map memory was going to be dumped. At the start of building the light maps it ran out of memory, this memory was going to be dumped later, but we didn't have enough left to finish creating the light maps.
I however, have found a solution for that
.
Quote: "but saying the process consumes no Memory at all is just... false advertising."
Defiantly isn't false advertising.
Quote: "The lightmapper could only consume 0MB if it isn't launched at all, or if it's a complete separate process - however, it would still consume memory then, just not memory from the main process - is is that what you meant with the "0MB usage"?"
No, building light maps on a separate thread is already what it does, and that wouldn't have anything to do with saving memory. I can assure you though, the light mapping no longer consumes any of the FPSC engine's virtual memory.
Quote: "With the lightmapping being 0mb does that mean the performance will boost?"
No, light maps are pre-processed so they shouldn't of taken away from performance in the first place.
