Saturday, March 22, 2008

« "Into Tomorrow"... Today! | Main | See You At The Virtual Worlds Conference In NYC-- And Get The NWN Discount Code Here »

How Neptune Got Its Glow: Procedural Overview For Neptune Lighting's OpenGL-Driven System (Updated)

Neptune_lighting_software_2

Lighting the Neptune bar with Neptune Lighting (click image for larger view)

Last Friday's post on the gloriously textured Neptune Bar has inspired an energetic conversation in Comments, and if you're interested in 3D graphics, it's catnip. There, Neptune Lighting's Tories Canetti explains in more detail how his company's process works, and refers us to this .pdf file for illustrated, step-by-step details:  The first step to process is to capture the scene for use in the renderer. We do that by using a custom OpenGL® driver which reconstructs the mesh and parameters from calls to the graphics library...

Judging the profoundly cool results, I'd call Canetti's innovations WindLight for Second Life architecture.

Update, 3/23: Added side-by-side comparison composite-- screen capture of NeptuneLight software taken from the company overview document [.pdf link], Neptune Bar exterior photo by JeanRicard Broek, who has a great round-up post on Neptune's Buzz here.

TrackBack

TrackBack URL for this entry:
http://www.typepad.com/t/trackback/742433/27368270

Listed below are links to weblogs that reference How Neptune Got Its Glow: Procedural Overview For Neptune Lighting's OpenGL-Driven System (Updated):

Comments

I wish I has this software to play with. I know a few of my buildings would look much better with shadow, refraction, "real" bump mapping, reflection, and glowing bits.

Bumpmapping in SL is heavily restricted to either the several built-in types, or luminosity-based stuff. Oh, and the fact that transparencies interfere with them.

The bump-mapping in SL has never made sense to me. Basically a bump map should be a height encoded into one channel. The renderer can then take the gradient in a per pixel manner and compute the N dot L lighting on a per pixel basis depending on the gradient generated normal and the direction from that point to the light.

I'm not sure how the bump mapping in SL works, but it doesn't appear to do that in the usual way. Basically if you set a bumpy material and then make another light source and move it around, the dark spots in the bumpy material don't appear to change a whole lot.

That being said, what does generally make light mapping "bake-able" is that it only depends on the vectors N and L, and not D (the vector to the viewer).

-Tories

Post a comment

If you have a TypeKey or TypePad account, please Sign In