Comments on: Lightmap Parameterization

By: Scott

Scott — Mon, 16 May 2016 20:58:35 +0000

Two more years have passed and I too am interested in the light map packing algorithm. Looks like it works really well!

By: Jonathan Blow

Jonathan Blow — Tue, 22 Oct 2013 00:01:40 +0000

In reply to Matthew Kenneally. We intend to release it, but I think Ignacio wants to be perfectionist about it... and we have a lot going on.

By: Matthew Kenneally

Matthew Kenneally — Mon, 21 Oct 2013 07:41:47 +0000

I too am interested in this algorithm. I guess this isn’t going to get released?

By: Alexis Naveros

Alexis Naveros — Sat, 06 Jul 2013 01:28:52 +0000

I fully agree with nexekho, that lightmap packing is very impressive! You said you planned to release the source at some point, 3 years have passed, how long must we suffer? :) Seriously, I really wish we could integrate such a nice algorithm within Blender, preferably without duplicating all the excellent work you have done…

By: nexekho

nexekho — Fri, 13 May 2011 17:53:46 +0000

Dude, if you can port that packing algorithm to Blender or Max… that’s just godlike, I’ve never seen a machine pack do such a good job!

By: Ignacio Castaño

Ignacio Castaño — Mon, 20 Sep 2010 18:09:48 +0000

@Carl: Lightmaps generally have low resolution and as a result are almost always magnified. However, for a game like this with large open spaces we would probably have some minification for objects that are far from the camera. My current plan to address that is to change the lightmap resolution according to the geometric LOD. For the lighting to stay coherent with the geometry we need to recompute lightmaps based on the LOD anyway, so instead of doing so at full res, we would use smaller lightmaps.

That said, the padding between charts is easily configurable so if we end up using mipmaps, we could tweak that easily.

By: Carl

Carl — Sat, 18 Sep 2010 01:53:06 +0000

This may be a dumb question, but is it standard practice to not use mip maps on lightmaps? Otherwise not having much of a gutter at all would be a problem.

By: Cody Burrow

Cody Burrow — Tue, 10 Aug 2010 04:11:25 +0000

Amusingly, I use a similarly colored checkerboard texture to check my UVs! I like the idea of fading between lightmaps for ambient light according to aperture states – will have to try that.

By: cb

cb — Wed, 09 Jun 2010 23:00:45 +0000

It seems to me a simplified version of SSP would be very easy.

Make your charts at higher res initially and do a temporary packing.

Now render the lightmaps.

For each chart, try downsampling it to lower res and measure the error; take the smallest downsample you can within error bound.

Repack the now shrunken charts to final texture packing.

By: Shalin Shodhan

Shalin Shodhan — Wed, 19 May 2010 08:56:12 +0000

Hey,
Have a look at Ptex:
http://ptex.us/

It’s a per-face UV mapping format that provides high quality filtering.
The hard part is of course doing this at run time… but it’s worth a look!

Cheers!
Shalin

By: Benoit FOULETIER

Benoit FOULETIER — Tue, 06 Apr 2010 08:28:35 +0000

Wow… this is the first article where I just about didn’t understand a word :) ! Though I like how technical this blog can get, the cascading shadows article was my limit I think: didn’t understand everything but gave me an overview.
This one… I don’t even get the premise; maybe a couple graphs in the beginning would have helped?

By: Reginald

Reginald — Thu, 01 Apr 2010 20:29:32 +0000

great article. I really like the brute force packing results, the Purelight people could really learn from that.

By: Alexey Orlov

Alexey Orlov — Wed, 31 Mar 2010 10:22:41 +0000

Hi Ignacio,
As a quick note, you can think of linABF as a pre-process for LSCM. It gives you angles for ideal parametrization, which needs to be converted to uvs. You can feed them to lscm when creating constraints matrix. That way you’ll get less distortion. As a plus, linABF is really fast, so it won’t hurt, and as you have solver/matrices in-place – it would be pretty straightforward to implement