VISIT COUNTER

Few days ago I was watching a movie "Illusionist", with a Victorian backdrop of  1800's. It was time in England when Chariots were the mode of transport,city of sophisticated people, army on Horses along city streets and a total monarchy. This reminds me of a classic, "Great Expectations" by Charles Dickens which I read in my school days. Although I had bibliophobia at that stage of my life and was more busy with my sports recreations, but the curicullam forced me to read it as I had to fill my answer sheets with something relevant to the book. But thanks to the curicullam designers to make me read this classic.

Great Expectations is a novel first serialised in All the Year Round from 1 December 1860 to August 1861. It is regarded as one of his greatest and most sophisticated novels, and is one of his most enduringly popular, having been adapted for stage and screen over 250 times.

Plot summary

The story is divided into four phases of Pip's life expectations.

On Christmas Eve, young Pip, an orphan being raised by his sister and her husband, encounters a frightening man in the village churchyard. The man, a convict who has escaped from a prison ship, scares Pip into stealing him some food and a file to grind away his leg shackle. This incident is crucial: firstly, it gives Pip, who must steal the goods from his sister's house, his first taste of true guilt, and, secondly, Pip's kindness warms the convict's heart. The convict, however, waits many years to truly show his gratitude.

At his sister's house, Pip is a boy without expectations. Mrs. Joe beats him around and has nothing good to say about her little brother. Her husband Joe is a kind man, although he is a blacksmith without much ambition, and it's assumed that Pip will follow in his footsteps. Only when Pip gets invited unexpectedly to the house of a rich old woman in the village named Miss Havisham, does Mrs. Joe, or any of her dull acquaintances, hold out any hope
for Pip's success.
Indeed, Pip's visits to Miss Havisham changes him. Miss Havisham is an old woman who was abandoned on her wedding day and as a result, stopped all the clocks in her house at that time only. She wears a yellowed wedding gown and haunts around her decrepit house, her only companion being Estella, her adopted daughter. Estella is beautiful, and Pip develops a strong crush on her, a crush that turns into love as he grows older. But it is unrequited love, as Miss Havisham has made it her dark life's project to raise Estella as a cruel-hearted girl who will break men's hearts, satisfying Miss Havisham's own desire to spurn love.



Pip frequently visits Miss Havisham, until one day she tells him never to return because the time has come for his apprenticeship with Joe to begin. Having tasted the spoils of a better life, Pip is miserable as a blacksmith and constantly worries that Estella will look through the forge window and see him as horribly common. Estella soon leaves the village, and things progress until one day Mrs. Joe suffers an attack which leaves her mute and incapacitated but much nicer. A young girl about Pip's age, Biddy, comes to live at the house in order to care for Mrs. Joe. Pip again settles into his routine, until one night at the village bar a London lawyer, Jaggers, approaches Pip, revealing startling news: Pip has inherited a sum of money from an anonymous benefactor and must leave for London immediately, to become a gentleman.

In London, Pip studies with a tutor and lives with a new and close friend, Herbert. Pip is certain that his benefactor is the rich Miss Havisham. In addition, he becomes convinced that Miss Havisham's financial support, toward his elevated social status, is the result of her desire that he may marry Estella someday. Pip passes many years in London; he remains ashamed of Joe, and they grow apart; Mrs. Joe dies, as he becomes more and more infatuated with Estella--who seems to get colder and colder by the day--he never confesses his love. Among the people he knows in London are Wemmick, a clerk in Jaggers' office who becomes a friend, and Bentley Drummle, a horrible brute of a boy who begins to become interested in Estella.

One stormy night, Pip learns the true identity of his benefactor. It is not Miss Havisham (who has made many misleading comments indicating it was her) but rather a petty criminal named Magwitch. Magwitch is the convict Pip fed in the churchyard many years ago, and he's left all his money to Pip in gratitude for that kindness and also because young Pip reminded him of his own child, whom he thinks is dead. The news of his benefactor crushes Pip--he's ashamed of him, and worse yet, Magwitch wants to spend the rest of his days with Pip. Pip takes this on like a dreadful duty, and it's all the worse because Magwitch is a wanted man in England and will be hanged if he's caught.

Eventually, a plan is hatched by Herbert and Pip, whereby Pip and Magwitch will flee the country by rowing down the river and catching a steamer bound for mainland Europe. This must be done on the sly, and further complicating matters is the fact that an old criminal enemy of Magwitch's, Compeyson, is hot in pursuit. Compeyson, it's discovered, is the same man that swindled and abandoned Miss Havisham so many years back. Miss Havisham, meanwhile, is softening a bit and seems repentant for her life-long mission against love.

Estella has been married to Bentley Drummle, a marriage that anyone can see will be an unhappy one. Just before Pip is to flee with Magwitch, he makes one last visit to Miss Havisham and finds her filled with regret, wanting his forgiveness. Unfortunately, she gets a little too close to the fire and sets herself ablaze. Pip heroically saves her, but she's badly burned and does eventually die from her injuries.

Pip and Magwitch, along with Herbert and another friend, Startop, make a gallant attempt to help Magwitch escape, but instead he's captured--pointed out, in fact, by his old enemy Compeyson. Compeyson dies in the struggle, and Magwitch, badly injured, goes to jail. Pip by now is devoted to Magwitch and recognizes in him a good and noble man. Magwitch dies, however, not long before he's slated to be executed. Pip has discovered that Magwitch is actually Estella's father, and on Magwitch's deathbed, Pip tells Magwitch his discovery and also that he loves Estella.

Without money or expectations, Pip, after a period of bad illness during which Joe cares for him, goes into business overseas with Herbert. Joe has married Biddy, and after eleven relatively successful years abroad, Pip goes to visit them out in the marshes. They are happy and have a child, whom they've named Pip. Finally, Pip makes one last visit to Miss Havisham's house, where he finds Estella wandering. Her marriage is over, and she seems to have grown kinder and wants Pip to accept her as a friend. When the novel ends, it seems that there is hope that Pip and Estella will finally end up together.






 

The first stage of Pip's expectations:

Pip, a young orphan, lives a humble existence with his shrewish older sister and her strong but kind husband, Joe Gargery. One day Pip meets Magwitch, an escaped convict, and brings him food and a file after the man threatens his life. This convict is later caught again and sent away.

Pip is satisfied with his life and his warm friends until he is hired by a wealthy woman, Miss Havisham, as an occasional companion to her beautiful but haughty adopted daughter, Estella. Pip falls in love with Estella. From that time on, Pip aspires to leave behind his simple life and be a gentleman. After years as companion to Miss Havisham and Estella, he spends more years as an apprentice to Joe so that he may grow up to have a future working as a blacksmith.

After a fight with Joe's assistant, Orlick, Mrs. Joe is found in the kitchen after a terrible attack.

This life is suddenly turned upside down when he is visited by a London lawyer, Mr. Jaggers, who informs Pip that he is to come into the "great expectations" of handsome property and be trained to be a gentleman on the behalf of an anonymous benefactor (whom Pip assumes to be Miss Havisham).

The second stage of Pip's expectations:

Pip travels to London. He arrives on a carriage near Mr. Jaggers' offices. After a stroll around the area, Pip is told by Mr. Jaggers that he will temporarily stay at the Barnard's Inn. Upon arriving, he finds Herbert Pocket (a relative of Miss Havisham), who informs Pip of Miss Havisham's past. Apparently, Miss Havisham had once been deceived by her jealous brother (Arthur Havisham) and an accomplice (Compeyson). Compeyson had misconstrued her into falling in love with him but had fled with her wealth, leaving her at the altar. Angered and humiliated, she raises Estella to take revenge on all males.

With Mr. Herbert Pocket, Pip receives an education and tutoring in manners, fine clothing, and cultured society. Whereas he always engaged in honest labour when he was younger, he is now supported by a generous allowance, which he frequently lives beyond. He learns to fit in this new milieu, and experiences not only friendship but rivalry as he finds himself in the same circles as Estella, who is also pursued by many other men, especially Bentley Drummle.

As he adopts the physical and cultural norms of his new status, he also adopts the class attitudes that go with it, and when Joe comes to visit Pip and his friend and roommate Herbert to deliver an important message, Pip is embarrassed to the point of hostility by Joe's illiterate ways, despite his protestations of love of and friendship for Joe. At the end of this stage, Pip is introduced to his anonymous benefactor, Magwitch, the escaped convict he helped long ago who has now acquired affluence in Australia. This revelation again changes his world and ends this stage of his expectations.

The third stage of Pip's expectations:

From this point on, Pip's life changes from the artificially supported world of his upper class strivings and introduces him to realities that he must deal with, including moral and financial challenges. He learns startling truths - including that Magwitch is innocent (framed by Compeyson) and that Estella is Magwitch's daughter. He realizes that he cannot accept Magwitch's fortune, is cast into doubt about the values that he once embraced so eagerly, and finds that he cannot regain many of the important things that he had cast aside so carelessly. Moreover, he discovers that Bentley Drummle has wooed Estella. Pip tries to warn Estella, but she ignores his admonitions and continues with the engagement.

Pip returns to Satis House and finds Miss Havisham distraught with remorse. Miss Havisham realizes that she has done Pip wrong and that she has also ruined Estella. She begs his forgiveness, which he quickly gives. Later, whilst sitting next to a fireplace, her dress catches fire, and she goes up in flames. However, Pip saves her though he burns his own hands. Miss Havisham loses her sanity and since then perpetually asks for Pip's forgiveness.

Pip soon receives an invitation by a mysterious stranger to the Marshes in his old town. There, he is kidnapped by Orlick, who despises Pip for smearing his reputation with Biddy whom he secretly admires. He admits to attacking Pip's sister and is about to kill Pip just when he is saved by Herbert.

They return to London and attempt to smuggle Magwitch from England to Hamburg, Germany on a foreign steamer. This attempt fails when Compeyson leads the police to the ship Magwitch is on. Magwitch seizes Compeyson, and a fight in the water ensues. Compeyson dies, and Magwitch is hit by the keel of the steamer ship, which was to take him away and is apprehended. Soon after, Mr. Wemmick marries Miss Skiffins, and Herbert leaves for Cairo, Egypt. Magwitch falls ill, and Pip tells him before he dies that his daughter (Estella) is still alive and that he loves her. Magwitch dies in peace, but Pip falls ill. Joe tends to him and pays the debts that Pip has accumulated. Pip eventually travels with Herbert as an occupation in the Middle East.

The ending

Charles Dickens wrote two different endings for Great Expectations. Dickens changed the ending at the suggestion of a friend, the novelist Edward Bulwer Lytton, presumably for the sake of a happier ending. The majority of books being published currently contain the first ending, or both, with the Dickens' original with its own explanation.

Original ending:

Pip meets Estella on the streets. Her abusive husband Drummle has died, and she has remarried to a doctor. Estella and Pip exchange brief pleasantries, after which Pip states while he could not have her in the end, he was at least glad to know she was a different person now, somewhat changed from the cold-hearted girl Miss Havisham had reared her to be. The novel ends with Pip saying he could see that "suffering had been stronger than Miss Havisham's teaching and had given her a heart to understand what my heart used to be."

Revised ending:

Pip and Estella meet again at the ruins of Satis House:

'"We are friends," said I, rising and bending over her, as she rose from the bench.

"And will continue friends apart," said Estella.

I took her hand in mine, and we went out of the ruined place; and, as the morning mists had risen long ago when I first left the forge, so the evening mists were rising now, and in all the broad expanse of tranquil light they showed to me, I saw no shadow of another parting from her.'

Not exactly. But the data from a satellite 423 miles high has been integrated into UbiSoft’s new game, Tom Clancy’s H.A.W.X., a modern jet combat game set above real-world locations (see the trailer here). The game debuts next week on various game consoles and the PC.

The data comes from the GeoEye Ikonos satellite, which can see things on the ground that are just 16 inches long. That data serves as the backdrop for ground maps in the game. UbiSoft’s game developers in Romania integrated the data with their 3-D elevation technology to create accurate terrain maps. They essentially drape the terrain data over a kind of relief map of the globe.
“The whole point is to give the gamer a real sense of authenticity,” said Mark Brender, vice president of communications and marketing at GeoEye. “It does a much better job than a cartoon map of immersing the player in the experience.”

So if you aren’t too busy with a dogfight, you can glance at the ground below to see where you are in the world. Washington, D.C.-based GeoEye is launching a new satellite as early as 2012, but the satellite imagery has been available for commercial use for some time. It’s an example of how technology once available only to government spy agencies has now migrated to the open market.

GeoEye was formed in 2006 when Denver-based Space Imaging and Orb Image Corp. combined. Space Imaging had launched the commercial Ikonos satellite in 1999. In September, the company launched its GeoEye-1 satellite.

The company has 502 employees and reported revenue of $181 million in 2007. The company is profitable and just

signed a $12.5 million-per-month contract with the National Geospatial Intelligence Agency. It also has a contract with Google to supply data for Google Earth. The GeoEye-2 could cost $90 million to $110 million to deploy. Its other U.S. competitor is Digital Globe in Longmont, Colo.

First off, I am going to introduce to you the major components of a "modern" shader. These components work together to give a surface the overall appearance of resembling some material. The first components I'm going to cover here are the most basic and common: Color, Incandescence, Specularity, and Reflectivity.

If you were to look at all of the vectors used to figure out all of these shading components, it would look like this:

Here you can see the first two vectors we covered earlier, the Lighting Vector (L) and the Normal Vector (N). Remember that comparing the directions of these two vectors tells us how much light is falling on that point. I will briefly describe these vectors again, as well as the new ones we see.

Normal Vector (N) - Points in the direction the surface faces at a given spot.

Lighting Vector (L) - Points from a spot on the surface to a light source.

Camera Vector (V) - Points from a spot on the surface to the camera viewing it.

Reflection Vector (R) - This vector is used to determine what part of the scene is being reflected off of a certain spot on the surface. It points from the surface out into the scene. Whatever it hits is reflected at that spot. It can be found by reversing the camera vector (V) so that it points at the surface, then adding 2 * ( N * dot(N, V) ). Confusing? Here's a step-by-step:

Half Vector (H) - The Half Vector is used for calculating the brightness of the specular highlight. By comparing its direction to the Normal Vector (N) (using the dot product) the specular value can be found. As H gets closer to N, the specular highlight at that point gets brighter. It is created by adding the Camera Vector (V) to the Lighting Vector (L), and dividing by 2. Thus, this vector is the average between L and V. Specular Value = dot(N, H), andH = (L + V) / 2.

The NV2 used the same rendering method and was never completed. It was to have been used in the Dreamcast console (which replaced the Saturn), but Sega finally chose a polygon-based technology (PowerVR) and Nvidia abandoned QTM in favor of polygon-based rendering with the NV3.

Riva 128 And Direct3D

In 1997, Nvidia’s move to polygon-based 3D yielded the NV3, better known under the name Riva 128. Little known fact: Riva stands for Real-time Interactive Video and Animation accelerator. Two versions of the chip existed: Riva 128 and Riva 128ZX. The difference was slight — the ZX had a faster RAMDAC, 8 MB instead of 4 MB of memory, and AGP 2x support. The Riva 128 enjoyed a certain level of success because its price was attractive, despite quality that sometimes left a bit to be desired compared to the 3Dfx products of the period. The Nvidia card offered 2D and 3D on the same card, as well as support for Direct3D. The OpenGL drivers were released only with the 128ZX, though specific Quake versions existed (though not a complete ICD).

The Riva 128 was popular with OEMs due to its price, which was below that of a Voodoo Graphics card and provided Direct3D performance that was nearly the same. This was one of the first AGP cards, even if the Riva 128 used the interface essentially as a faster PCI bus. Finally, and somewhat amusingly, a very well known manufacturer was a competitor of Nvidia’s for performance with one of its graphics cards: Intel, with its i740. Times have changed.

NV4: Twin Texels For The TNT  
















 

In 1998, 3Dfx had a high-performance 3D card in the Voodoo2, but the card had major limitations. These included archaic memory management (separate textures), a 16 bit color ceiling, the need for a separate 2D graphics card, and PCI-only interface (in practice, though AGP models did exist). Then the Riva TNT arrived on the scene, which was a fast 3D card with a lot of memory (for the time) and built-in 2D capabilities. Except for video performance — it had no MPEG2 acceleration, as ATI’s cards did — the TNT was a success. It was the first Nvidia card capable of applying two textures in a single pass, thus the name TNT for “TwiN Texel”. 

The TNT was a less powerful card than originally planned. Nvidia had wanted to bring out a faster card than the Voodoo2, using a 250 nm process with a clock speed of 110 MHz (200 MHz for the memory). In fact, the TNT used a 350 nm process and had a clock speed of 90 MHz, like the 3Dfx card, with the memory running at 110 MHz.


 

NV5: The First Ultra

In 1999, the TNT2 made its appearance. It was close to what the TNT was originally supposed to be, and can be thought of as a die shrink of the TNT from 350 to 250 nm. This was also the first time Nvidia used the name Ultra for one of its cards. 

The TNT2 cards were segmented in terms of frequency. At the time, Nvidia used only two versions (far from today’s bewildering assortment): TNT2 and TNT2 Ultra. The TNT2 was a powerful card for its time, easily a match for the Voodoo3 while offering more features, even though there was still no MPEG2 decoding. It was also Nvidia’s first AGP 4x card, even though that standard wasn’t really used with the TNT2. 

The NV6, which also came out in 1999, was a cut-down version of the TNT2. It was sold under the name Vanta, Vanta LT and TNT2 M64. These cards were significantly slower than the TNT2 (and the original TNT), essentially because of their lower clock frequency and 64-bit memory bus. They were very successful with OEMs, however, who used the name “TNT2” as bait.

















 

GeForce: The First GPU

Late in 1999, Nvidia announced the GeForce 256. This was the first card to use what Nvidia called a “GPU,” but its major advance was really consumer hardware support for T&L (transform and lighting). This technology, already being used in Open GL and in professional 3D, performs calculations on triangles on the graphics card instead of on the CPU. The actual gain was considerable in certain cases, since the graphics card had approximately four times the power of a high-end CPU of the time (15 million triangles for the GeForce, as opposed to four million on a 550 MHz Pentium III). 

The card used a different architecture from the TNT2. Instead of two rendering pipelines, each equipped with a texture unit, there were four pipelines with one texture unit, which gave the GeForce more rendering power at a lower clock frequency. The GeForce 256 was also the first card to use DDR SDRAM, increasing memory bandwidth. 

Nvidia moved directly from NV6 to NV10 for the GeForce 256, and the nomenclature of the following models was in steps of five, with variants for the low/high-end models. Also, the GeForce 256 was the first Nvidia card to handle MPEG2 acceleration, but only partially (Motion Compensation). Finally, this was also the first consumer card with a DVI connector (via an external chip).

NV15: Nvidia Improves The GeForce 256

In the year 2000, Nvidia had a fast graphics card — the GeForce 256 DDR — but ATI was starting to get more competitive with its Radeon, which was both faster and more efficient. Nvidia responded with a new card, the GeForce 2 GTS. Using a 180 nm fab process, the card was noticeably faster than the GeForce 256. It doubled the number of texture units from 1 to 2 per rendering pipeline, which enabled the application of eight textures in a single pass. Nvidia released several versions of the card: the GTS (GigaTexel Shader, 200/166), Pro (200/200) and Ti (250/200). 

In August 2000, pending the release of the GeForce 3, Nvidia put out the NV16 (GeForce 2 Ultra). This was not a new card, rather an NV15 with higher clock frequencies: 250 MHz for the GPU and 230 MHz for the memory, compared to 200 and 166 MHz on the original card. This was also one of the most expensive cards

NV11: The First Low-End Version

The GeForce 2 GTS had great performance, but also a high price tag, and Nvidia needed to offer a card for gaming enthusiasts who couldn’t afford to spend a small fortune on a computer. The company’s answer was the NV11, the GeForce 2 MX, also released in 2000. Unlike the TNT2 M64 and Vanta, which in reality were nothing more than an NV5 with a 64-bit memory bus, the NV11 had a new architecture derived from the GeForce 2 GTS. Nvidia did away with part of the rendering pipelines, but for multitexturing a GeForce 2 MX had more power than a GeForce 256. 

This was the first Nvidia card that could manage more than one display, and that function was to remain part of Nvidia’s midrange cards for a few years. The GeForce 2 MX had only SDR memory and was also the first GeForce to be released in a mobile version (the GeForce 2 Go). 

Nvidia brought out several versions of the GeForce 2 MX in addition to the standard model and the Go version. These included the MX400 (equipped with a GPU clocked at 200 MHz), the MX200 (with a 175 MHz GPU and 64-bit memory bus at 166 MHz) and the very poor MX100, with a GPU clocked at only 143 MHz and 32-bit memory (0.6 GB/s bandwidth). Finally, some rare cards were equipped with 64-bit DDR and were basically equivalent to the 128-bit SDR versions.

Enter The GeForce 3 



 

In 2001, the GeForce 3 made its appearance. This card, the first to be DirectX 8 compatible, supported programmable pixel shaders. With 57 million transistors, the card used fairly conservative clock speeds and a GeForce 2 Ultra could outperform it in many cases (at the time it was released). The card brought a few improvements in memory management, but its complex architecture prevented Nvidia from developing an entry-level version. 

Nvidia offered two different versions of the GeForce 3: the Ti 200, which was a little less expensive than the original, and the Ti 500, which was more expensive. The former was clocked at 175/200 (GPU/memory) and the latter at 240/250 MHz.

The GeForce 4 That Was A GeForce 2 


 

Moving ahead to 2002, Nvidia had a card with performance in the GeForce 3, but it was too complex. Creating a new card based on its architecture (as had been done with the NV11) was a difficult proposition, and so Nvidia used the architecture of the GeForce 2 to create the NV17, marketed as the GeForce 4 MX. The cards used the same architecture as the GeForce 2 MX — two pipelines capable of rendering two textures — but ran at higher clock rates. The cards also used the memory management introduced with the GeForce 3, had hardware MPEG2 decoding, and supported multiple displays. Still, they were DirectX 7 cards, and so were outdated from the time they were launched, despite adequate performance in some cases. 

The line included three cards: the MX420, MX440 and MX460. The first was clocked at 250 MHz for the GPU and 166 MHz (SDR) for the memory; the second ran at 275/200 (DDR), and the third at 300/275 (DDR). 

In addition to the 420, 440 and 460 versions, Nvidia offered mobile versions (GeForce 4 Go), AGP 8x versions (with the NV18 chip, the only improvement), and even a PCI Express version in 2003: the PCX4300, with an AGP 8x-to-PCI Express 16x bridge.

NV2A: A GeForce In A Console 


 

In 2001, Microsoft introduced its first game console, the Xbox. It was very close to a PC in terms of architecture. It used an x86 processor and ran Windows — and the graphics card was from Nvidia. The NV2A, as it was called, is an intermediate chip between the GeForce 3 and GeForce 4. It was well-optimized in the Xbox and supported DirectX 8.1 (through the console’s NT5 kernel), enabling the console to offer some very graphically impressive games for its time. 

For the Xbox 360, ATI supplied the GPU and Nvidia went over to the enemy with its RSX chip used in the PlayStation 3.

An Improved GeForce 3: The GeForce 4 Ti 


 

The successor to the GeForce 3, released in February 2002, was called the GeForce 4 Ti. Its architecture was similar to that of the NV20 (GeForce 3), but the NV25 was significantly faster due to its 150 nm process. Nvidia gave the GeForce 4 Ti approximately three times the Vertex Shader power of the GeForce 3 by increasing the clock frequency and doubling the number of ALUs. In addition, Nvidia improved LMA, the technology that limits memory bandwidth use by not calculating undisplayed data. 

Nvidia sold three versions of the card: the Ti 4200, the Ti 4400 and the Ti 4600. The differences among the cards was in the clock speeds: 250 MHz for the GPU and 250 MHz for the memory (Ti 4200); 275/275 for the Ti 4400; and 300/325 for the high-end Ti 4600. 

Late in 2002, the NV28 arrived. This GPU was similar to the NV25, simply adding AGP 8x support to the GeForce 4 Ti cards. The GeForce Ti 4800 (300/325) was identical to the GeForce 4 Ti 4600 except for the addition of AGP 8x compatibility. The GeForce Ti 4200 128 MB had a lower bandwidth than the 64 MB version because the memory ran at 222 MHz compared to 250 MHz in the 64 MB version.

NV30: Nvidia Loses With The FX 5800 


 

NV3x: Nvidia Releases FX (and PCX) Versions 


 

Even after the failure of the NV30, Nvidia kept the architecture, with the GeForce FX 5900 replacing the GeForce FX 5800. With its 256-bit memory bus and improved vertex calculating power, the FX 5900 managed to hold its own against competing cards like the Radeon 9800 Pro. Nvidia also released entry-level and midrange versions of its GeForce FX: the FX5600 (NV31) and FX5700 (NV36) in the midrange, and the entry-level FX5200 (NV34). These cards are noteworthy in that the earlier midrange card (the GeForce 4 Ti 4200) could outperform them. 

Nvidia also released PCI Express cards — the GeForce PCX series — but they were essentially AGP cards with an AGP-to-PCI Express bridge. Some FX 5200 cards had a 64-bit bus (instead of 128-bit) and a slower memory clock frequency (166 MHz instead of 200 MHz)

N40/N45: Nvidia Gets Back In The Race With The GeForce 6800 and SLI 


 

After the failure of the NV30, it was imperative of Nvidia to snap back. And they did, with the NV40, also known as the GeForce 6800. This card was extremely efficient and more powerful than the FX 5900, due to its large number of transistors (222 million). The NV45, also called GeForce 6800, was nothing more than an NV40 with an AGP-to-PCI Express bridge, giving the card support for the new standard, and above all, for SLI. The SLI technology couples two PCI Express GeForce 6 cards to increase performance. 

Cards based on the NV41 and NV42 were also produced. The NV41 is an NV40 with fewer processing units (12 pipelines and 5 vertex units) used in certain GeForce 6800 cards; the NV42 is an NV41 fabricated with a 110 nm process (and thus, less expensive to produce).

GeForce 6 Invades The Planet 


 

After the GeForce 6800, Nvidia needed to introduce cards that were slower and less expensive. The NV40 was powerful, but its 222 million transistors limited fabrication yields and increased the price, so the two cards built from it, the GeForce 6600 and 6200, had only moderate success. The GeForce 6600, fabricated at 110 nm, was based on the NV43 and offered good performance at a decent price. The PCI Express versions of these cards could even operate in SLI mode. 

The GeForce 6600 was the first natively PCI Express Nvidia card; AGP versions used a PCI Express-to-AGP bridge. The GeForce 6200 was an entry-level card — not very powerful but not very expensive. PCI Express, AGP, and PCI versions were produced, and there were also versions built into laptops. 

The GeForce 6200 was the first TurboCache card from Nvidia. In addition to the dedicated memory (16 to 512 MB), the card can use system RAM as video memory. Some manufacturers took advantage of this to tout the GeForce 6200 as “256 MB,” when in fact it had only 64 MB of dedicated memory. Note also that a built-in version of the NV44, the GeForce 6100, was included in certain Nvidia chipsets. The chip used a 90 nm process and had a single rendering pipeline and no dedicated memory.

G70 and G71: Nvidia Changes Its Nomenclature 


 

In 2005, Nvidia announced the GeForce 7. The GPUs’ code name, which had traditionally been NVxx, changed to Gxx. The first card was the G70 (GeForce 7800), followed fairly quickly by the G71 (GeForce 7900). More powerful than the 6800 series, the GeForce 7800 was a success for Nvidia. The cards were sold in many different versions, such as the GTX and GS. AGP versions with a PCI Express-to-AGP bridge were also sold. 
With  the GeForce 7900 Nvidia also used, for the first time, a technique its competitors had already been using: dual-GPU cards. The 7900GX2 and 7950GX2 had two G71s in parallel. The company was to re-use this technique in 2008 with the GeForce 9800GX2.

G72 and G73: Low-end GeForce 7s 


 

As has become its habit, Nvidia released two other versions of its high-end architecture — one entry-level (G72, GeForce 7300) and one midrange (G73, GeForce 7600). Both chips were fabricated with a 90 nm process and offered adequate performance. As is often the case, the mobile versions used the midrange chips, and the GeForce 7300 Go was very popular. 
Slower (7200 Go) and faster (7400 Go) portable versions were also produced, and an 80 nm version of the G73 was also sold by Nvidia.




























 

Nvidia And The 8800: GeForce 8 Or GeForce 9? 


 

In November 2006, Nvidia announced the G80. This chip and its derivatives were destined to have a long life. In fact, as of 2008, some of the fastest cards available from NVIDIA were still using a chip that’s very close to this G80 (the G92). Nvidia got as much mileage as possible out of the G80 and the move to a 65 nm process with the G92 allowed the company to save money on the cost of the chip. Nvidia varied the number of stream processors, the width of the memory bus, and clock speeds, in order to produce a plethora of GeForce 8800 and 9800 versions. There’s even a version with 2 GPUs: the GeForce 9800GX2. 
The GeForce 8800 series cards were all DirectX 10 compatible, and Nvidia scored a great success with this series, pending the arrival of the GeForce GTX. 
Just for a laugh, let’s run through all the GeForce 8800 series cards that have been released: the 8800GS 374, 8800GS 768, 8800GTS 320, 8800GTS 640, 8800GTS 640 v2, 8800GTS 512, 8800GT 256, 8800GT 512, 8800GT 1024, 8800GTX 768 and 8800 Ultra 768. Then there’s the 9600GSO 512, 9600GSO 384 and 9600GSO 768, and the 9800GX2 and 9800GTX — not to mention the future 9800GTS and 9800GT. And that’s not counting the mobile versions!

Entry-Level GeForce 8s 


 

To be able to market economy versions of the card, Nvidia had to severely modify the G80. Given the number of transistors, it was out of the question to use it as-is. So the company offered three chips, more or less: the GeForce 8400 (G86), GeForce 8600 (G84) and GeForce 9600 (G94). Other versions existed (GeForce 8300, 8500, and so on), but those three models are the major ones. The G84 was much used in notebooks, as a high-end card, whereas in desktop PCs it was only a midrange GPU. 
The GeForce 8600 and GeForce 8400 were as mediocre as the G80 and GeForce 8800 were successful. The spread between high-end and midrange cards (before the arrival of the GeForce 9600) is very wide for this generation, which causes problems for gamers.

The Xbox GPU consists of two main parts, which are the GPU core (500MHz) and the eDRAm Die.

The GPU communicates with the Xbox's CPU through its BIU (Bus Interface Unit), which is directly connected to the CPU's FSB (Front Side Bus). The BIU is also connected to the main memory through the two GDDR3 memory controllers while the I/O unit connects it to the South Bridge. According to Microsoft, this configuration cuts down on latency when the CPU needs access to large chunks of main memory.

The GPU core also communicates with the main memory and the I/O circuit (South Bridge chip) through another unit, called the Memory Hub, which is directly connected to the memory controllers. The display controller is also fed with buffered frames through the Memory Hub unit. Notice that the Xbox uses an external (outside the GPU) DAC chip for video conversion.

Two GDDR3 memory controllers (2 x 64bit) are connected to the main 512MB memory. Each controller communicates with 256MB GDDR3 memory kits, at a maximum speed of 22.4GB/sec.

The eDRAM Die unit is manufactured by NEC (90nm process) and consists of an array of 192 processors, responsible for pixel processing such as anti-aliasing (AA) and alpha/Z processing etc. Microsoft has added a 10MB eDRAM memory unit for rendering inside the eDRAM Die directly connected to the rendering unit (256GB/sec), in order to avoid utilizing resources from the main memory. The eDRAM Die unit is contained in the GPU unit.

The CPU

The Xbox 360 is equipped with a huge 3-core CPU running at 3.2 GHz. A 1MB L2 cache is shared among all three CPU cores, and the communication with the GPU is achieved through a 21.6GB/sec FSB (Front Side Bus) channel.

South Bridge Connection through PCI express

The GPU is connected with the South Bridge chipset (I/O controlling unit) through a dual PCI Express interface (10GB/sec). The South Bridge chipset also includes an XMA decoder for audio, reducing the load on the CPU. The external I/O interfaces include SATA (20GB hard drive, 12x DL DVD recorder), USB Memory Unit ports (MU), ethernet controllers etc. The provided I/O interfaces look similar to those that will be found in Sony's Playstation 3.

GPU and CPU transistors

The GPU core unit uses 232,000,000 transistors while the eDRAm Die (Pixel processing unit) use 100,000,000 transistors.

The 232M transistors on GPU unit is about 40% more than those found on ATI's RADEON X800 (R420/423) GPU, and is almost equal to NVidia's GeForce 6800(NV40) system (222,000,000).

However, considering that Microsoft's early announcements for the Xbox concerning 48 Unified-Shaders, 232M transistors seems small. This might mean that ATI has possibly used some new techniques in the Unified-Shader design.

For comparison reasons, the GeForce 7800 GTX (G70) from NVIDIA uses 302,000,000 transistors for 32 Shaders. The RSX (Reality Synthesizer) GPU" installed in the Playstation 3, has a composition similar to the G70.

In addition, Microsoft disclosed the number of transistors of the Xbox 360 CPU. The CPU unit uses 165,000,000 transistors, a number equal to that found in a Pentium 4 6xx (Prescott 2M) CPU.

On the other hand, IBM's Cell processor on the Playstation 3 uses 241M transistors, which is roughly 1.5 more than those found on the Xbox.

Level: Intermediate

Area: Graphics Programming

Summary

This document is an introduction to the series of samples, tutorials, and articles known as the Shader Series. This is a serial set of educational documentation and sample code that should allow an intermediate 3D developer to begin to explore the programmable graphics pipeline.

Audience

This document will be most useful for developers with some previous experience with either the fixed-function pipeline or the BasicEffect type in the XNA Framework. This document assumes no previous experience writing shaders or effects.

Background

History

In 1999, Microsoft introduced an important new feature in DirectX 7 that came to be known as hardware transformation and lighting, or hardware T&L. The new technology moved the expensive vertex transformation and lighting calculations from the CPU to the GPU. The DirectX 7 API exposed an elaborate set of state values that allowed a fixed number of lights, textures, and other states to be applied to a given draw function.

While hardware texturing and lighting had an incredible impact on the quality of 3D graphics on the personal computer, there was a significant drawback. The calculations used to light and display the world were hard-wired on the GPU. As a result, games of that time began to look very similar, since they couldn’t differentiate their lighting models except by applying different states. The era of universal 3D acceleration had raised the overall quality bar, but at the cost of the flexibility afforded by software rendering.

In the field of offline software image rendering for movie special effects, small programs or functions called shaders were increasingly being used to define custom interactions between a variety of materials and lighting conditions. Real-time applications were soon to follow; in 2002, the first consumer level programmable GPUs became available. Game developers were eager to make use of the new functionality. Most early consumers of programmable GPUs associated shaders with the classic rippling water effect, which at the time was considered the height of real-time graphical “eye candy.”

DirectX 8.0 was the first Microsoft graphics API to support programmable shaders, though initially, all shader programs had to be written in assembly code. As shader hardware increased in complexity, so did the programs. High-level shading languages were introduced to make shader development manageable. Today, Microsoft high-level shader language (HLSL) is the standard language used by all Microsoft 3D APIs, including the XNA Framework. The language compiles directly to the byte code used to execute shaders on GPUs.

Shaders have evolved greatly over the years. Generations of shader hardware are usually categorized by the DirectX shader models they support. Early shader models had extreme limits on the kinds and number of instructions that could be run on each vertex or pixel. Later models defined more instructions, added larger numbers of instructions per shader program, and enabled looping and branching functionality. Many XNA Windows materials are written with a minimum bar of Shader Model 2.0, while the Xbox 360 platform supports its own version of Shader Model 3.0. These models have the flexibility to support a huge number of rendering and optimization scenarios.

High-Level Shader Language (HLSL)

HLSL is the programming language created by Microsoft for writing shaders. It is similar to many C-style languages. The DirectX SDK is a great place to get more information about HLSL. A very complete set of documentation on HLSL can be found here:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/directx9_c/HLSL_Shaders.asp.

A full description of HLSL is outside the scope of this document. Familiarity with HLSL is not required for the rest of this document, but the link above is a great starting point for further reading.

Often the best way to learn something is to jump straight in. All of the upcoming example shaders are labeled and commented in such a way to make comprehension more straightforward. This document assumes no previous experience with HLSL and attempts to clarify new HLSL grammars as they come up.

Other Shader Languages

There are plenty of other high-level shader languages available, but HLSL is the only language supported intrinsically by XNA and DirectX. Other common languages are GLSL (Open GL Shading Language) and NVidia’s Cg language. When non-XNA materials reference these languages, they essentially fill the role that HLSL does for DirectX.

Effects

Introduction to Vertex Shaders

Vertex shaders expose functionality that was originally hard-coded into fixed-function hardware texture and lighting. Vertex shader programs are functions run once on each vertex passed into a Draw call. They are responsible for transforming raw, unlit vertices into processed vertex data usable by the rest of the graphics pipeline. The input of the vertex shader corresponds to the untransformed data in the vertex buffer.

At the bare minimum, a vertex shader only needs to return a transformed position.

Introduction to Pixel Shaders

Pixel shaders add a level of control not available in classic fixed-function pipelines. To understand a pixel shader, you have to know a bit about what happens after the vertex shader runs. The processed vertex data is used to set up triangles, which in turn are used to determine which pixels on the screen will be drawn. The input to the pixel shader is calculated using the vertex shader outputs from each of the triangle's three vertices.

The inputs of a pixel shader function are therefore bound to the outputs of the vertex shader. So if a vertex shader returns color data, the pixel shader inputs may include this color data. The data is typically interpolated using the three surrounding vertices. For example, imagine an equilateral triangle. Each of its three vertices is a different color. One is red, one is green, and one is blue. The color input to the pixel shader will be calculated by linear interpolation on those three colors. Pixels that are close to the red vertex will be mostly red, pixels that are closer to the blue vertex will be blue, and the pixel in the exact center of the triangle will have equal parts of red, green, and blue.

At a minimum, pixel shaders must output color data. Pixel shader outputs translate directly into the colors seen on the screen. Pixel shaders are primarily used for a number of per-pixel color operations, including texturing, lighting, and image processing.

Introduction to Effects

Effects combine the ideas of vertex shaders, pixel shaders, and graphics device states into one common file format. XNA supports shaders primarily through effects, so they are central to the idea of writing your own shader programs. An effect file is a text file that contains the HLSL code used by any number of vertex and pixel shaders. 

An effect contains one or more techniques, which are in turn made up of at least one pass. Each pass usually contains one vertex shader function, one pixel shader function, and any number of render state and sampler state settings. In the next section, we’ll look as a simple example effect and go over each line in detail.

Examining a Simple Effect

float4x4 mWorldViewProj;  // World * View * Projection transformation

float4 Vertex_Shader_Transform( 

    in float4 vPosition : POSITION ) : POSITION

{

    float4 TransformedPosition;

    // Transform the vertex into projection space. 

    TransformedPosition = mul( vPosition, mWorldViewProj );

    return TransformedPosition;

}

float4 Pixel_Shader() : COLOR0

{

    return float4(1,1,1,1);

}

technique ColorShaded

{

    pass P0

    {          

        VertexShader = compile vs_1_1 Vertex_Shader_Transform();

        PixelShader  = compile ps_1_4 Pixel_Shader(); 

    }

}

This effect is one of the simplest effects that will produce a useable render. This shader will take a world-view-projection matrix and render white geometry based on its vertex positions. We’ll now break this shader down and explain each part in detail. 

HLSL Semantics

In the code listing above, a syntax that may be somewhat unfamiliar are the capitalized keywords that follow a variable and a colon. Consider the following line of HLSL code:

in float4 vPosition : POSITION

The POSITION keyword is called a semantic, which has an important place in HLSL code. These keywords indicate to the shader compiler how to map the inputs and outputs of the graphics data to the shader variables. In this example, vertex position data is being mapped to an argument called vPosition.  This informs the shader that the vPosition argument will contain position data from the vertex buffer. 

This document will explain the usage of semantics as they come up in the effect code.

HLSL Types

float4 TransformedPosition;

One aspect of HLSL programming that will quickly become intuitive is the different primitive types available when initializing variables. In this case, a float4x4 primitive is used, indicating a matrix of four floats by four floats. A Vector3, which is a structure of three floats, is a float3 in HLSL.  HLSL defines a number of primitive types, and a robust documentation can be found here:  http://msdn2.microsoft.com/en-us/library/bb206325.aspx.

Also provided here is a table mapping some basic HLSL types to their .NET or XNA Framework equivalents.

Effect Parameters

Effect parameters are the uniform data that remains constant for every vertex or pixel processed by the Draw call. These can be initialized in the effect, though many times it’s only appropriate to set these values in the render loop. Effect constants are used to represent a variety of things, but most commonly they’ll represent transformation data, light settings, and material information.

float4x4 mWorldViewProj;  // World * View * Projection transformation

Only one constant has been specified in the example effect. In this case, it’s the world-view-projection matrix used to transform the vertices drawn from object space into clip space.

By itself, this uninitialized parameter isn’t all that helpful. The application must provide this data. The XNA Framework API facilitates this assignment using the EffectParameter type, which is used to get or set the value of the parameter in the effect. The following condensed example shows how one might set the above matrix in C# code.

worldViewProjParameter.SetValue(worldViewProj);

Uniform and Varying Inputs

The data that makes shaders function comes in two flavors: varying and uniform. Varying data is unique to each execution of the shader function. In the case of vertex shaders, it’s the data that comes from the vertex buffer. For pixel shaders, it is the data specific to the individual pixel being rendered.

The other type of data is uniform, and it includes data that applies across the entire draw call. This is also referred to as constant data, and is treated differently. The developer can set the values of any of the shader constants through the Effect API. In the previous example, one of the constants was a float4x4 (a 4x4 matrix of floating-point values) called mWorldViewProj. In the XNA Framework API, the developer can look up the wvp field by name and set it to a matrix available in the application. In this example, the matrix being set is the word-view-projection matrix information required by nearly every basic vertex shader.

Vertex Shader Function

Vertex shaders take a variety of inputs, and the values of these inputs vary for each vertex rendered. Usually, there’s a one-to-one correspondence between a vertex shader’s inputs and the structure of the vertices in the supplied vertex buffer.

float4 Vertex_Shader_Transform( 

         in float4 vPosition : POSITION ) : POSITION

In the provided example shader, the vertex shader takes a single input:  the untransformed vertex position. The way that the shader informs Direct3D what the purpose of each variable is through semantics. In this case, the POSITION semantic is applied to vPosition, meaning that vPosition will correspond to the x, y, and z-coordinates of a vertex.

There is a second POSITION semantic declared after the function declaration. This semantic applies to the float4 return value of the vertex shader function. This is an output semantic that informs the effect compiler that the return value is a transformed position.

Next, the body of the vertex shader function will be examined, starting with the first line:

    float4 TransformedPosition;

Here, we’re initializing a variable that will hold the results of the vertex shader. This is a structure of the type float4. The syntax for declaring a local variable is similar to variable initialization in C# or other C-style languages.

Transformation Pipeline

In the fixed-function pipeline, the actual transformation function was hidden from the developer.  In the programmable pipeline, shader flexibility is contingent on allowing the developer to apply transforms as needed.

In this example, the vertex shader is responsible for transforming the incoming vertex data. This requires a calculation in the shader that multiplies a position vector by a world-view-projection matrix. 

    // Transform the vertex into projection space. 

    TransformedPosition = mul( vPosition, mWorldViewProj );

This calculation transforms the vertex position from model space to projection space. These transformed positions are used by the geometry processing portion of the Direct3D pipeline to define the triangles that make up primitives on the screen. This is a matter of a simple multiply (the mul function in HLSL). That function in the shader is identical to calling Vector4.Transform(vPosition, mWorldViewProj) in the XNA Framework.

For more information about world-view-projection transforms, see the “Coordinate Spaces” article.

Returning Data from the Vertex Shader

The last part of the vertex shader function simply returns the output from the shader. Like C++ and C#, the return keyword is used to return the vertex shader outputs.

    return TransformedPosition;

The Pixel Shader Function

float4 Pixel_Shader( ) : COLOR0

The first thing to note is that the pixel shader is returning a float4 value. This value represents the color of the pixel after the draw call. A pixel shader’s primary function is to return the color of the current pixel. Like the vertex shader, a semantic (COLOR0) is defined for the return value of the function.

Most simple pixel shader functions will only ever return an RGBA color. In most shaders, color values are represented by floating-point vectors with 0.0 being completely dark and 1.0 as the maximum or “fully-on” state. The graphics hardware then translates this value into a color that is meaningful in the context of the current back-buffer format.

 return float4(1,1,1,1);

There’s not much to this pixel shader, since the vertex shader has done all the hard. The pixel shader simply returns a white color. This means that all of the triangles drawn with this shader will appear flat-white.

State Setting

The last part of the effect is used to set state on the GraphicsDevice. It tells the device how the shader functions should be used.

technique ColorShaded

{

    pass P0

    {          

        VertexShader = compile vs_1_0 Vertex_Shader_Transform();

        PixelShader  = compile ps_1_4 Pixel_Shader(); 

    }

}

This section informs the effect of which shaders to apply using a given technique or pass. An effect file may contain several techniques. However, for this example, the effect is limited to a single technique. Passes are included to allow multiple-pass renders, which are common in more complex shaders. In this example, “P0” refers to the name of the pass.

There are only two states being set in this technique – the pixel shader and the vertex shader. The compile command also indicates what shader model to which to compile the shader. For now, it’s best not to get bogged down by shader model specifics. The samples all use appropriate shader models for the techniques being employed.

There are lots of other states that can be set in the technique. For example, nearly all of the render states and sampler states available on the GraphicsDevice can be set in the technique code. This is a useful way to organize specific states with their accompanying shaders. Later samples in the Shader Series will cover more of these states in depth.

Simulating Fire

Computer graphics researchers have long placed a significant emphasis on rendering aesthetically pleasing fire in 3D. Until now, efforts have failed to realistically capture the physical characteristics of fire. The natural randomness and turbulence of fire typically leads to a rendering solution based on well-understood calculations, such as Perlin noise and Gaussian distribution-based particle systems. These visual effects all point to a common model of fire but do not demonstrate the physical properties of fire beyond a single flame source. Intel’s Smoke demo combines a traditional particle system that captures the visual effects of fire with a secondary system that treats fire as a heat source. This heat emitter dictates how a fire spreads by following a fuel source, how intense the fire is at any particular position, and the proximity of the heat source to another fuel source.

Implementation

Objects in Smoke

The Smoke demo architecture1 uses individual components defined as systems that house typical game engine features, such as physics, graphics, audio, and AI. A typical game entity in Smoke is an abstract object linked to several systems. For example, a horse in Smoke’s farm scene has the following systems:

• Graphics for the model and skeletal animation

• Geometry to control position and orientation

• Physics for collision detection

• Audio for sound effects

The structural logic is the same for every object in the scene, such as the meteors that rain down from the sky, which include the graphics, physics, and audio systems as well as the fire system. The fire system is responsible for the demo’s physical and visual properties of fire.

Fire System

Smart Particles

The procedural fire system consists of two discrete parts: a particle emitter based on a particle system inspired by Luna2 that includes billboard flame textures (fire particles) and a heat emitter system that models the heat property of fire (heat particles). These graphics are show in later fi gures to differentiate the two particle systems. A fuel source, such as a tree in the Smoke demo, consists of multiple branches and canopies (for each leaf cluster). However, any geometry, including meteor objects, can be a potential fuel source. Each branch and canopy of a tree can serve as a host to the fire’s smart particle system.

The system can use the host object’s axis- aligned bounding box (AABB) to not only determine where the visual flame particles should be positioned but also to conduct collision checks in the heat emitter. Just as in a real fire, heat tends to spread upward and away from a heat source, moving up

a tree from branch to branch, finally reaching the canopy. At the same time, fire can occasionally spread downward, following the path of a canopy to a branch as indicated in

Figure 1.

Figure 1. The smart particle system—fuel source detection as a

heat particle intersects a bounding box.

Fire Particles Heat Particles

Spreading Fire

Meteor objects are the only objects in the scene that are initially burning. They also serve as hosts for the fire system, and as they fall through the scene some may pass near an element, such as a tree, that is also associated with the fire system. Trees in the demo consist of branches and canopies, each of which is an individual geometric object. If that object is not already burning, the fire system’s collision-detection algorithm will set it on fire, further propagating fire throughout the tree and potentially to other trees in the scene. The heat emitter’s collision check is a time-intensive computation well-suited to r un within Smoke’s highly parallel, task-oriented architecture. Each burning object consists of several individual fires that represent a visual particle system and a physical fire particle from the heat emitter. In terms of the collision check, the fire particle is treated like a ray and is tested against an intersection of an adjacent fuel source’s AABB. The magnitude of this ray approximates the physical nature of a fire’s heat to set that object on fire. Objects that are outside the range of this ray are not affected.

Figure 2 shows how a collision between a heat emitter and a branch will mark it as burning. This activates that object’s visual particles and heat emitter, allowing the fire to spread. The process repeats over time until all fuel sources within range are on fire. Each fire object is iterated against all branches that are on fire and checked against each heat emitter to detect if there is a collision with an adjacent fuel source.

The algorithm for this check consists of the following pseudo code:

The deepest piece of this code performs the actual intersection test between the heat emitter’s heat rays in Tree A and a branch in Tree

as shown in Figure 3.

Because the heat particle belongs to a heat emitter in a different object, that fire’s heat particle must be translated into the local space of the other geometric object (see Figure 3).

Figure 3. A translation and collision test to translate heat

particles from Tree A to Tree B.

Figure 4. A meteor spreading fire to a standing tree.

Fire System Parameters

The fire system includes a set of input values for the visual and heat-emitter particle systems that control

individual particles: • Type (spherical fire for meteors, line for branches, patch for canopies) • Fire density (how many heat emitter or visual particles exist for a single burning element) • Size (the rendered billboard’s size)

• Impulse (impulse velocity vector applied to guide fire in a default direction)

• Shift (upward position adjustments to guide fire direction)

• Lifetime (how long do the heat emitter and or visual particles live)

The following images depict the initial spherical fire from the meteor catching a tree on fire (Figure 4), then spreading throughout that tree (Figure 5), and ending with the fire spreading to another tree (Figure 6).Rendering Fire, Smoke, and Embers The visual particle system used to render the flame billboards uses a sequence of textures alternating over the lifetime of the particle. This creates the transition

of a growing flame expiring into smoke and embers that rise above the tree in a towering plume implemented in Ogre* 3D3 shader code.

Figure 5. The fire system spreads upwards, following the

fuel sources.

Figure 6. Once the initial tree is fully ablaze, the fire spreads

to the next tree.

AN OVERVIEW OF HOW TO ACCURATELY MODEL PROCEDURALLY SPREADING FIRE

Water

The Smoke demo includes a water hose (8) that allows users to move around the scene and extinguish the fire caused by the falling meteors. As already noted, each fire object—in this case an entity

bound to the geometric tree object—is iterated over every branch that is on fire. The fire object is checked against each heat emitter contained in the fire for a collision with an adjacent non-burning branch. Water is a natural extension of the fire system, and additional checks are used to extinguish a burning element in the collision checking code and to prevent the water from spreading, as the fire does, to another object. Much like the geometric meteors use an attached fire system that is parameterized to start fires as a heat emitter, the invisible geometric cold object has a fire system instance set as a cold emitter, enabling it to participate in collision detection and to interact with other fire system objects. The Smoke demo uses the Particle FX plug-in provided in the Ogre 3D package for its script-based

particle system. Collision detection occurs through the fire system that is bound to an invisible geometric object fired from the camera’s position like a rapid-fire projectile. As the water object passes by or collides with a burning object, the attached fire system determines if any of the cold emitter’s rays intersect with a burning object, thereby extinguishing the fire. An added bonus to this effect is that the invisible water object is also bound to Smoke’s multi-core-compatible Havok4 physics system, allowing the water object to act as a projectile and to interact with destructible elements in the scene, such as the farmhouse.

Intel does not make any representations or warranties whatsoever regarding quality, reliability, functionality,

Figure 8. The fire system—water introduced as a cold emitter

                                                                                    Author: Atul Sharma

                                                                                                Game Developer

                                                                                                Ubisoft Entertainment India Pvt. Ltd.

What is XNA

XNA is the latest Gaming API to come out of Microsoft. It can be thought of as a successor to Managed DirectX and brings the intuitiveness and power of .NET 2.0 to graphics programming that was hitherto unavailable. 

To gain a better understanding of XNA and where it fits in the graphics topology, it would be instructive to look at the predecessors of XNA and correlate them to some of the offerings in the programming landscape.

XNA Genealogy:

• GPU Programming <=> Assembly:

 At the very beginning was GPU programming, before the time of HALs [Hardware Abstraction Layers] where you had to go direct to the metal - one had to program directly for the GPU in the instruction set of the chipset. Very similar to Assembly language programming in the early days of programming where the code you wrote for the Intel 8088/8086 was not compatible with the Motorola 68000 series. Similarly there was a huge porting effort required to get the code written for an ATI chipset to work for an alternate GPU vendor. Further, one had to be really accomplished to get anything done and developer productivity was really low due to the lack of any advanced tools.

• Direct3D 7.x and lesser <=> C:

 With the evolution of the HAL [Hardware abstraction Layer], one could target a virtual graphic platform/framework such as Direct3D on Windows and it would use the HAL to port the code automatically to the specifics of the chipset that it was running on. While this made code porting (for different chipsets) a thing of the past, it was still not very sophisticated in terms of developer productivity tools. This can effectively be compared to the C programming language that provided effective platform abstraction but still was not a very sophisticated programming language.

• Direct3D 8,9 <=> C++:

Direct3D 8&9 evolved on the previous versions and simplified Direct3D programming to a certain extent. The main addition worth calling out is the support for fixed function pipelines that simplified 3D programming to a large extent. The ability to use C++ and Microsoft libraries for programming 3D makes it comparable to C++. It was definitely an evolution over the previous versions and provided more support to the developers.

• Managed Direct3D <=> Visual Basic:

 Managed3D (as part of Managed DirectX [MDX]) was the first step in attempting to bring 3D programming to the masses. Up until then, programming Direct3D required a level of commitment that was only possessed by professional graphics programmers. Managed D3D or MDX in general, implemented a .NET based wrapper interface around DirectX that made it possible to target DirectX using any .NET language. The wrapper attempted to eliminate many idiosyncrasies of DirectX and provide more intuitive and streamlined API for programming DirectX. Further, it is unnecessary to state how much .NET simplifies programming compared especially, to a language such as C++. It reduces complexity by many orders of magnitude as compared to programming D3D using C++. So, in this regard, MDX can be thought of as doing what Visual Basic did to programming.

• XNA <=> Winforms [C# or VB.NET]: \

And finally, XNA, is an evolution on MDX, instead of just being a wrapper around DirectX, it provides more of a .NET based framework that is built on top of .NET 2.0 and DirectX9.0c [as of current writing], that provides a programming model that is more intuitive than anything that has been seen in the world of Graphics programming. It allows you to take all of your experience and expertise as a managed programmer and apply it to 3D programming. Programming Direct3D with XNA feels as natural as programming a Winforms app - you don't worry about all the housekeeping chores and the very first lines of code that you start writing are directly for your game logic. For e.g., All drawing in D3D happens on an object called a "device" and programming D3D on MDX or with C++ requires that *you* create the device, set a bunch of properties on the device and then use the device for doing the actual drawing, whereas in XNA, the device is automatically created and handed to you and the first line of code you write is to use the device for your game. So, to sum up, the following are the 2 main (well, there are 3 actually, but I will save the last one for later in this post) contributions of XNA:
1. Consistent .NET 2.0 programming model. All major .NET 2.0 design guidelines are followed.
2. Automatically handles a lot of the boiler plate stuff, so that you only worry about coding the game logic.

Why XNA

Now that we know what XNA is, let us now examine "Why XNA?"!
Is XNA the greatest technological breakthrough in the world of Graphics till date? Probably Not! It is still based on DirectX 9 and leverages .NET 2.0 for its programming model. So, there is nothing revolutionary about the underpinnings of the technology. However, it has gobs of evolution written all over it. Not since the creation of the HAL has programming graphics become so much more accessible. Leveraging the extremely intuitive programming model of .NET 2.0 and applying that model to programming Graphics is probably the next biggest evolution since .NET 1.0 in the Microsoft development landscape.

The above alone would be sufficient reason to migrate to XNA, however, the BIGGEST contribution of XNA is its ability to target the XBOX 360 (This is the other contribution of XNA that I was talking about in the above section). Yes, that's right!! Now, just about anyone can write graphics/game programs on their PC and without any significant porting effort, send and run it on their retail XBOX. Now, to ask a rhetorical question: "Why care about the 360?!"

I can see you guys rolling your eyes and going: "Duh!!?" But this sets me up perfectly to talk a bit about the really cool architectural details of the 360 in my next post. It may be worth noting that within 10 short months of the 360 releasing, it currently boasts over 7 Million uses and over 60% of that crowd are on XBOX Live which is one of the highest adoption rate in the online services field. It is also architecturally, the most advanced console available today.

Here are the reasons why XNA would be a great platform for students to be programming in following their intro Graphics course.

To set the context, XNA is a completely managed (.NET 2.0 based) API that targets Direct3D 9.0 (for its Graphics functionality) under the covers that provides a seamless programming experience for Windows and the XBOX 360. Right off the bat, here are the obvious advantages:

1. Extremely straightforward programming model: You are not stuck worrying about passing long pointers back and forth as in the case of C++ over DX. Since it is based on .NET, all the memory allocation/dealloc are taken care of, so no more worries about memory leaks and dangling pointers <whew!>.

2. Simplified API: My constant feedback from people getting started on DirectX is that the API and the DX structures are too complicated. XNA cleans up and simplifies the API to a very large extent thereby leading to code that flows well and makes sense at first glance.

3. No infrastructure maintenance: You don’t have to worry about writing the 50 or so lines of code just to get your device up so you can start painting - the XNA framework automatically initializes the device and passes a handle to you so that the first lines of code are for your game - not for infrastructure initialization. And this is true not just for device creation, but also in a lot of other cases, where the theme of XNA is to take care of the grunt work in handling device states and let the programmer work on just the game logic and drawing features. However, this does not mean that you have no control over the nitty-gritty - almost all features can be controlled by tapping into the right event handlers prior to initialization, so, if you want a custom backbuffer, just do it before device creation, just like you would with good ol' DX.

4. No portability issues: For me, this is the killer part - write your code once and have it run on both Windows and the XBOX 360 with almost no changes. The framework abstracts away the platform differences and lets you target multiple platforms with a single codebase. No porting effort required.

5. Simplified content import model: Instead of an export based model for content as we are used to with DX, XNA features a content import pipeline that will work with models and media of various vendors and make the process of importing and using those assets a breeze.

I could go on and on, but the above are the key distinctions of XNA. Apart from the Graphical capabilities, the XNA framework also provides support for Audio, Math and Storage. Furthermore, a lot of game engine vendors are embracing XNA and making their offerings available in XNA as well - a case in point: the very popular TorqueX engine from Garage Games.

In most of the talks that I do on XNA, the students are extremely interested in the 360 platform, where they can convert their Graphics homework assignments and Game development hobbies into a 10 foot experience that they can share with their entire family. Also factor in potential support for XBOX Live (which is in the cards eventually), and the 360 is suddenly the coolest platform to target to showcase your work and get noticed.

To sum up, I know it has been a long write-up (I am just really really excited about this technology), but for the typical student profiles, this would be an ideal platform.

XNA (and DirectX 10) only support the programmable pipeline, so you can write Shader based programs that would be cross-platform (Windows and XBOX) compatible. Students with prior Graphics experience could come in, be productive on day 1, writing Games and Game/Visualization components in XNA that they could showcase on our MSDN-XNA community site, and get noticed. Students with no Graphics experience would be able to focus on starting their learning without worrying about the nuts and bolts of the infrastructure or worrying about the idiosyncracies of the language, and delve directly into the conceptual features that they are trying to master.

I hope I have been able to give you an idea in terms of the capabilities and power of this new offering and am always available for any additional questions or concerns