Archived

This topic is now archived and is closed to further replies.

reaptide

Hardware Lighting VS. Lightmaps/Lit Vertices

Recommended Posts

Hello everyone, I was just wanted to know if anyone considers it viable on today''s current video hardware (GeForce 2 & 3, Radeon, etc...) to exclusivily use hardware lighting instead of other lighting methods (Lightmapping, Vertex Lighting, etc...). I''m asking this because the game I''m working on won''t be using any more that six to eight lights at a time (Mostly directional and point lights) and using hardware lights may be quicker than using other methods.

Share this post


Link to post
Share on other sites
sure, that sounds okay. but if you really want to make the world look good, lightmapping is the cheap and easy way to go.

a2k

Share this post


Link to post
Share on other sites
Oh yeah. I forgot about that little quirk. For most of the game that wouldn''t be a problem, but there may be some very large surfaces in a small number of places.

Time to consult the design team

Share this post


Link to post
Share on other sites
Its been viable to use hardware lighting (or at least T&L pipeline lighting) for a good number of years. In fact its the more suitable way of doing things on cards which predate multitexture (ie. pre-Voodoo2ish).

The trick is tesselating the geometry where it counts (possibly on the fly) [see comment above about large flat surfaces] and and not doing any per-frame calculation where it doesn''t count (if a diffuse light hasn''t moved in relation to a vertex since previous frame, its influence is the same as it was the previous frame).

We did a demo for nVidia sent to some press organisations around the time of the launch of the original GeForce which was doing around 85,000 polys per frame with 3 lights, all vertex lit and in hardware (It used to be on the Riva3D site) - its been possible since then!

We also used vertex lighting (T&L) exclusively in Pac-Man:Adventures in Time and scaled depending on whether T&L was in hardware (although one factor was the publisher wanted it to run on pre-multitexture hardware).


For our future high end stuff, we''re looking at moving away from vertex lighting (apart from stuff like cel shading), and lightmaps and heading for per-pixel only solutions (DOT3, pixel shaders etc, BEMs for refraction etc) - we''ll probably use vertex lighting as a fallback for people with legacy hardware.


BTW: Vertex lighting *IS* hardware lighting ?! - or do you mean pre-calculated coloured vertices and software lighting ?


--
Simon O''''Connor
Creative Asylum Ltd
www.creative-asylum.com

Share this post


Link to post
Share on other sites
quote:
Original post by S1CA
Its been viable to use hardware lighting (or at least T&L pipeline lighting) for a good number of years. In fact its the more suitable way of doing things on cards which predate multitexture (ie. pre-Voodoo2ish).

The trick is tesselating the geometry where it counts (possibly on the fly) [see comment above about large flat surfaces] and and not doing any per-frame calculation where it doesn''t count (if a diffuse light hasn''t moved in relation to a vertex since previous frame, its influence is the same as it was the previous frame).

We did a demo for nVidia sent to some press organisations around the time of the launch of the original GeForce which was doing around 85,000 polys per frame with 3 lights, all vertex lit and in hardware (It used to be on the Riva3D site) - its been possible since then!

We also used vertex lighting (T&L) exclusively in Pac-Man:Adventures in Time and scaled depending on whether T&L was in hardware (although one factor was the publisher wanted it to run on pre-multitexture hardware).


For our future high end stuff, we''re looking at moving away from vertex lighting (apart from stuff like cel shading), and lightmaps and heading for per-pixel only solutions (DOT3, pixel shaders etc, BEMs for refraction etc) - we''ll probably use vertex lighting as a fallback for people with legacy hardware.


BTW: Vertex lighting *IS* hardware lighting ?! - or do you mean pre-calculated coloured vertices and software lighting ?


--
Simon O''Connor
Creative Asylum Ltd
www.creative-asylum.com


But can vertexlighting look as well as lightmaps if you have 85K tris in a scene?
Im doing a HW only 3D game and Im considering lightmaps or not. If I want my game to run on a GeForce1 what option would be better in your opinion?



The quickest way to double your money is to fold it in half and put it back in your pocket.

David Hof
Destiny3D engine programmer
mail - icq - homepage

Share this post


Link to post
Share on other sites
It all just depends on how dense your triangles are. Basically, you can think of it this way:

"Vertex lighting" is Gaurad shading - the light color of each vertex is calculated, and is then interpolated linearly across a triangle.

The problem is that a good light shading function isn''t linear; it''s a curve. One of the most common (and a very good one, especially for things like plastic) is Phong shading. It is a curve. So the problem is that Gaurad shading represents a line (imagine a graph) while more accurate methods use curves (again, imagine a graph). Using more triangles allows for more lines. Using lines, you can approximate a curve, and the more lines there are, the more closely that curve can be approximated.

If you want to dynamically scale your geometry to use Gaurad shading as an approximation of a Phong shading curve, then you''ll need to break up your geometry. You could do it arbitrarily, in a grid perhaps, but that wouldn''t make too much sense, would it? After all, the flatter portions of a curve shouldn''t have as many lines approximating them as the more sharply curved portions. Likewise, geometry should be tesselated with the angle between the surface normal and the light and the intensity of the light in mind.

There are also methods to simulate teh appearance of phong shading using specular highlight maps, which are used in combination with standard Gaurad shading.

But if you want Doom3 quality lighting, I''m not sure what to tell you. (Aside from "It''s not happening!!") Read up on pixel shaders!!

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
If we''re talking about dynamic lighting, HW lights can be OK, with dynamic tesselation. But for general static lighting, they are not. Because they are missing a small but absolutely vital component: shadows. Compare a lightmapped scene calculated by a good radiosity algorithm, and the same scene with hardware lights, and you''ll see what I mean... And even for dynamic lights: I don''t think hardware lighting will be the future. Realtime radiosity is the way to go. As CPUs get more and more powerfull, this will eventually get possible in the near future, and it will be 100% lightmap based. It will enable features such as realtime soft shadows and area lights.

- AH

Share this post


Link to post
Share on other sites
The exact lighting method used and how well it works is pretty dependent on the scenes the game has to show and the types of lighting required.

If you have hardware pixel shaders you can do some fairly nice looking diffuse (although not as correct as radiosity) and specular (can get some very accurate looking stuff with BEMs and dynamic envmaps) illumination.

On pre-pixel shader hardware (GeForce 1 etc) the types of lighting depend on the performance you require, how many polys you''re trying to push around, how dynamic the scenery is, how dynamic the lighting is etc...

- For indoor, artifically lit scenes (standard FPS or 3rd person FPSs*) where the light sources never move, precalculated lightmaps (say using radiosity) "look" the best... until you need to move the scenery or light or you start overlaying dynamic lights in the scene or need to do any bump mapping.

- If you want easy support for pre-multitexture cards without requiring multipass or you have lots of dynamic light sources **which can intersect** vertex lighting can be a good choice.
Vertex diffuse can look ok on characters even at low tesselation, specular however looks crap unless you tesselate a lot. All vertex lighting suffers on large flat areas (floors) unless you tesselate a hell of a lot (moreso than with characters).

- On GeForces, Radeon, Permedia3, Kyro and above, you have DOT3 which allows some very nice per-pixel lighting - the problem is it burns a texture stage so if you want multiple lights you need multiple passes. If you want to attenuate the light or add specular and glossmap you end up needing more passes (up to 3 more if you want to support 2 simultaneous texture multitexture cards)

If you can live without radiosity pre-lighting and only one dynamic lightsource, dot3 can look very nice, even with low tesselation (so you can save polygons for the extra passes), and you get free bump mapping if you put the normals into a texture - a perfect example of what it can look like is Malice (Argonaut) on XBox (although it does look like it could do with more agressive glossmapping). You can end up with some very nice lighting models with a bit of thought (pull out the maths, look at those dot products, Fresnel terms, which vectors are represented by environment maps etc)


Having said that, what we''re looking at and many others in the industry seem to be too is a hybrid approach scaled based on LOD and hardware...

For example one thing which looks nice is doing the diffuse lighting on the vertices (BTW, could pre-calculate vertex colours using radiosity too if you wanted to), and the specular and evironment per pixel

* A 3rd person first person shooter is what I term games which are essentially FPSs where the designers have realised their game is worse than all other FPSs causing them to stick a character in the place where the gun usually goes in an FPS in a bid to make the game seem "different"

--
Simon O''''Connor
Creative Asylum Ltd
www.creative-asylum.com

Share this post


Link to post
Share on other sites
So in other words lighting is always a doubleedged blade...

Thanks for the info.

[edit]

Just FYI, Im highly reluctant to go with lightmaps because of the massive texturestage changes required for every frames plus I'd like to keep the AGP bus free for uploading vertices (the game would have dynamic worlds etc) and with dynamiclightmaps you use a lot of bandwidth.

[/edit]



The quickest way to double your money is to fold it in half and put it back in your pocket.

David Hof
Destiny3D engine programmer
mail - icq - homepage

Edited by - Countach on August 9, 2001 9:01:26 AM

Share this post


Link to post
Share on other sites
Another thing to consider is on pre-Geforce 3 cards you either used NVidia''s lighting or you don''t get that HW T&L, and therefore you''re stuck with certain lighting styles. However, on the Geforce 3, you get that cool programmable lighting. I can''t tell you much more since I haven''t been able to get my hands on some of that hardware. I do know someone who has a Geforce 2 and I''ve compared the real-time NVidia demos with the MPEG Geforce 3 demos and the best upgrade besides the higher numbers of triangles is the lighting.

And I like to keep the AGP bus free too, unless you''ve got AGP 4x, then you can be a little more lax. But you can''t assume that everybody''s got 4x, some people still have, gasp,PCI hardware.

Share this post


Link to post
Share on other sites