| Wednesday, January 17, 2007 |
  Jpeg 2000 | 
Posted - 1/17/2007 12:08:41 PM | No, i didn't forget Shadowing part II. But as i have a lot to say, i need to block an hour or more in order to write the "article" :)
Today's theme is Jpeg2000. I have spent a bit of time investigating exactly what is the status of Jpeg2000 and if it's usable in Infinity.
Jpeg2000 is a much, much improved version of the old Jpeg standard. It supports alpha channels. It can be lossy or lossless. It supports 16 bits per component. It allows one to decompress an image of a lower resolution directly into memory ( without having to decompress to the original resolution and shrink it ). And best of all, at equivalent disk space usage ( imp.: to Jpeg ), it has a much higher quality. Often when Jpeg is very compressed, you can notice small artifacts: blocks of 8x8 pixels. This is no longer the case with Jpeg2000. Of course, higher compressions still mean loss of details, and the image gets blurry - but the artifacts are no longer visible..
All of those are excellent reasons to switch to Jpeg2000 in Infinity. But there's one thing to be careful about: that's performance. Jpeg2000 has a price..
So today i evaluated two Jpeg2000 libraries: J2K-codec ( http://j2k-codec.com/ ) and Jasper ( http://www.ece.uvic.ca/~mdadams/jasper/ ). I must add that i'm mostly interested in the decoding ( loading ) performance.
Jasper is considered to be pretty slow, but it's open source. J2K has a free trial but costs a small fee to be used in commercial project ( nothing to stop me if it's good ). J2K claims to be up to 54 times faster than Jasper. So i had to make a few benchmarks to see if it's true, and if the performance is usable.
The results are as follows:
A. The reference is loading a TGA image of 1024x1024 RGB, weighting 3 MB, uncompressed. When the hard drive cache is warmed up, it takes 14 ms on my Pentium D 830 @ 3 Ghz with a standard hard drive. I'm not sure how to disable the hard drive cache, so the result is flawed, as it's mostly a bandwidth operation rather than an I/O operation. It would probably be 3 or 4 times slower if the file was read for the first time.
B. Loading a JPEG version of the image, compressed to 171 KB, using the OpenIL image library. Takes 71 ms. That'll be another good point of reference: if loading a Jpeg2000 image is much slower than that, it won't be good.
C. Loading a JP2 version of the image, compressed to 154 KB, using J2K: 180 ms.
D. Loading a JP2 version of the image, compressed to 154 KB, using Jasper: 1390 ms ( ouch ! ).
Here we got a speed up of 7.7 times when using J2K over Jasper. That's nice, but the problem is that even in J2K, it is still 2.5 times slower than reading an equivalent Jpeg...
Next, i decided to vary a bit the compression ratio ( the lowest, the more compressed it becomes, and the less disk space it takes ):
J2K:
385 ms at 80%
253 ms at 10%
180 ms at 5%
150 ms at 3%
135 ms at 2%
117 ms at 1%
Jasper:
1670 ms at 80%
1472 ms at 10%
1390 ms at 5%
1345 ms at 3%
1320 ms at 2%
1310 ms at 1%
The interesting thing is to notice how J2K speeds up with higher compressions. A file compressed at 1% of its original size is loading 2.1 times faster than one compressed at 10%. This effect doesn't happen in Jasper: a 1% file loads 1.12 times faster than a 10% one..
Finally, let's see how it scales with resolution:
J2K at 10%:
253 ms at 1024x1024
64 ms at 512x512
17 ms at 256x256
Jasper at 10%:
1472 ms at 1024x1024
325 ms at 512x512
180 ms at 256x256
Infinity uses high resolution textures: 1024x1024 and 2048x2048. At those resolutions, J2K is between 5 to 10 times faster than Jasper, but it's still 3 times slower than Jpeg... it's a bit disapointing. I'm still wondering wether to use Jpeg2000 or not.
| |
| Shadowing part I | |
Posted - 1/12/2007 11:53:58 AM | On Shadowing:
I spent the last two weeks working on shadowing.
The following journal update will be quite technical, so you're warned !
In graphics programming, there are tons of shadowing techniques available for real-time usage, and they all - no exception - have good and bad points.
I'll start with a quick review of shadowing techniques and how they've been used in various games.
Lightmaps: is a static method. In a pre-processing phase, all the geometry of the level is uniquely uv-mapped ( at a very low resolution, generally a few tens of pixels per square meter ) and lighting/shadows are embedded into textures, called lightmaps. Lightmaps are then later multiplied by the diffuse texture. Absolutely useless for Infinity, no pre-processing is allowed in any algorithm ( shadowing or not ) due to the size of the universe. Plus all entities are dynamic..
Lightmaps are a thing of the past, typically used in old games such as Quake 3 / Unreal. They assume the "level" is small enough so that all lightmaps fit into video memory.
Stencil shadows (also called shadow volumes): is a dynamic method, used in Doom3-type games. They work by extruding the silhouette of the objects as seen by the light, forming a shadow volume in space. The stencil buffer is then used to trace virtual rays from the camera, counting how many times they enter/leave a shadow volume. The final test acts as a boolean and tells if the pixel is shadowed or not.
The main drawback of stencil shadows is that they're not robust ( they assume the objects are closed, ie. have no holes ) ( note: yeah, i know. It's possible to make robust stencil shadows. I'm simplifying for people who aren't so technical.. ). One thing you can't do with stencil shadows are alpha masks, since it works on the geometry itself.. the typical example is the foliage of a tree, which uses textures, while the geometry is a set of quads. Finally, the performance is heavily dependant on CPU, transforms and fillrate. The CPU bottleneck can be removed by implementing stencil shadows on the GPU, but the other bottlenecks are harder to get ride of. Basically, performance of stencil shadows is very dependant on image resolution and complexity of geometry. Hence why Doom3 doesn't have very complex 3D models..
This performance isn't so bad when your lights are point lights and affect only a small range - again what Doom3 proposes, strange coincidence, heh ? :) -. When the range affected by the light ( hence shadows ) grows, performance decreases quickly. The worst are directional lights which stress fillrate ( drawing shadow volume pixels ) a lot. For a single directional light, you could easily render tens of small-range point lights.
The most important light in Infinity being the sun(s), it needs to support directional lights at a high performance. Plus, the 3D models are quite complex geometrically.. hence goodbye shadow volumes.
Shadow mapping: ah, the good old shadow mapping.. the easiest to understand, but maybe the hardest to implement. Shadow mapping involves two steps: first, rendering the scene from the light's point of view into a depth (Z) buffer, also called a shadow map ; then rendering the scene normally from the camera's point of view, and for each pixel, check if the distance between the pixel and the light is smaller or equal than the one stored in the shadow map projected back on this scene.
Shadow maps don't require to extrude any geometry, ie. the rendering cost of the shadow map is only dependant on the amount of geometry in the light frustum, no new geometry is created ( unlike shadow volumes ). It can also use alpha masks, so no problem for vegetation foliage or other alpha-based effects ( again unlike shadow volumes ). And unlike shadow volumes, it suffers from aliasing.. and that's a very, very bad thing (tm) !
Aliasing is the effect of the limited resolution of the shadow map when it's projected back onto the scene. While shadow volumes ( using the stencil buffer ) give a pixel-perfect shadow, shadow maps will use the same shadow result for an area of pixels. This is because a set of pixels on screen that are very close to each other end up being projected onto the same pixel in the shadow map, so the shadow result ends up being the same. It looks aliased, it looks ugly..
As for performance, even though shadow maps are IMO a bit better than shadow volumes, they're far from coming for free. It mostly depends on the area you want to be shadowed: rendering shadow maps for an area of 100 meters doesn't have the same cost than an area of 10 KM. Especially if you want a good quality..
Let's imagine for a moment that your scene is roughly a square of 100 meters, and that your directional light uses a shadow map of 1024x1024 pixels ( i'll round it to 1000x1000 so that results look more simple ). With uniform ( standard ) shadow maps you get a virtual resolution of 10 cm. Good enough..
Now, if your scene is 10 Km big, a 1000x1000 shadow map will give you a resolution of 10 meters. In Infinity, a fighter or an interpcetor is around 10 meters long. The conclusion is simple: if using standard shadow maps, an interceptor would make one huge shadowed blob, one dot in the shadow map. Increasing the resolution of the shadow map to 2048x2048 would slightly help, but a resolution of 5 meters is still not enough.. and a scene of 10 Km isn't so large when you consider that a Flamberge is 5 Km...
Another problem with shadow maps is the shadow acne ( Z-fighting of shadowed areas ) especially when light is at 90° with a polygon's normal. Fortunately it's possible to get ride of those issues and have excellent quality shadows. I'll discuss that more in details in my next update.
Next time i'll discuss about various improvements to shadow mapping: some that i have already experimented ( per-object shadow maps, cascaded shadow maps ), some that i might experiment ( light-space shadow maps, deformed shadow maps ), and some that i will likely not bother with ( perspective shadow maps, trapezoidal shadow maps, variance shadow maps ).
While waiting, here's a screenshot of cascaded shadow maps. The skybox is copyrighted to the Minas Tirith project - i was lazy to replace it by another one, fix the shaders, the lighting, etc.. It wil give you an idea of the challenge of supporting objects with very different scales.
The interceptor is around 15m, the intrepid around 600m, and the Flamberge in the background, around 5000m.
| |
|
| S | M | T | W | T | F | S | | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | | 13 | 14 | 15 | 16 | | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | | | |
OPTIONS
Track this Journal
ARCHIVES
October, 2009
August, 2009
July, 2009
May, 2009
April, 2009
March, 2009
February, 2009
January, 2009
November, 2008
October, 2008
July, 2008
June, 2008
May, 2008
April, 2008
March, 2008
January, 2008
December, 2007
November, 2007
October, 2007
September, 2007
August, 2007
July, 2007
June, 2007
May, 2007
April, 2007
March, 2007
February, 2007
January, 2007
December, 2006
November, 2006
October, 2006
September, 2006
August, 2006
July, 2006
June, 2006
May, 2006
April, 2006
March, 2006
February, 2006
January, 2006
December, 2005
November, 2005
October, 2005
September, 2005
August, 2005
July, 2005
June, 2005
May, 2005
April, 2005
March, 2005
February, 2005
January, 2005
December, 2004
October, 2004
September, 2004
August, 2004
|
