Okee, ik weet niet helemaal onder welke catagorie het valt, maar gisteren kwam ik via de developer afdeling van nVIDIA aan een interactieve demo die Realtime per pixel lightningdemonstreert. Deze demo is speciaal ontwikkeld voor kaarten die Transform and Lightning ondersteunen, en vertoont een aantal fraaie dingen die met per pixel lightning kunnen worden bereikt.
Mijn vraag luid nu: Met alle "disco verlichting", spectacular lightning, bumbmaps etc. etc. aan behaal ik op mijn Geforce2 GTS behaal ik maar 12 frames per seconde, zou dit een reële vergelijking zijn met aankomende next generation (doom, kreed etc.)games die per pixel lighting gaan ondersteunen?
Link: http://www.ronfrazier.net/apparition/index.asp?appmain=research/advanced_per_pixel_lighting.html
Mijn vraag luid nu: Met alle "disco verlichting", spectacular lightning, bumbmaps etc. etc. aan behaal ik op mijn Geforce2 GTS behaal ik maar 12 frames per seconde, zou dit een reële vergelijking zijn met aankomende next generation (doom, kreed etc.)games die per pixel lighting gaan ondersteunen?
Link: http://www.ronfrazier.net/apparition/index.asp?appmain=research/advanced_per_pixel_lighting.html
Download: http://www.ronfrazier.net/apparition/downloads/advanced_per_pixel_lighting.zipApplying Depth Mapped Shadows to Point Lights
While the normal depth mapped shadow technique is quite useful, it has one inherent limitation in applying it to point lights and other 360° lights. The problem is that the depth mapping is designed to work within the confines of a frustum. In order to shadow a point light you need to combine six 90° frustums and project 6 depth maps out over the scene. Examining this in detail, we can see we need to render 6 textures to build the depth maps, and then we need to project all 6 of these depth maps out over the scene. This means we would need 12 rendering passes per point light. Now, by careful scene management, we may be able to determine that if no objects move within one or more of the frustums, and the light itself does not move either, then those frustums can be preserved from frame to frame. In the ideal case (where nothing in the scene moves) we can eliminate all 6 of the passes required to build the depth map. Additionally, if we accepting some inaccuracy then we can decide to only rebuild the cube map every other frame (or even less often). However, projecting the depth map still requires 6 passes per frame per light. In addition, these 6 passes are only for 8 bit precision. Rendering the depth map in 16 bit resolution requires 3 rendering passes per frustum, for a total of 18 passes per frame per light. This is definitely not desirable