 |
|
|
|
|
|
||
|
|
||
|
|
||
|
|
|
|
|
|
||
|
|
||
|
|
||
|
|
|
|
|
|||||||||||||||||
Add Forum to Favorites | Send Topic To a Friend | View Forum FAQ | Track this topic |
Last Thread Next Thread |
| Dual Paraboloid Mapping in the Vertex Shader |
|
 |
Enrico Member since: 4/5/2004 From: Stuttgart, Germany |
|||
 Posted - 4/17/2006 7:22:17 AM |
||||
| The download link for the .fx file does not work :-( |
||||
|
||||
|
Drew_Benton GDNet+ Member since: 7/29/2004 From: Katy, TX, United States |
|||
|
Posted - 4/17/2006 7:37:04 AM |
||||
Here are the links to the files I found via google  Might want to send a PM to a moderator or staff member or leave a post in the CSI forum about this so it can be corrected.dual_paraboloid_environment_map.fx dual_paraboloid_terrain.FX "But I, being poor, have only my dreams. I have spread my dreams under your feet; tread softly, because you tread on my dreams." - William Butler Yeats |
||||
|
||||
 |
Jason Z GDNet+ Member since: 2/4/2004 From: Royal Oak, MI, United States |
|||
 Posted - 4/17/2006 10:21:58 AM |
||||
| If you click on the 'Source Code' tab of the article legend, you'll get a zip file with both .fx files. I PM'd SiCrane about the links in the text, so hopefully they will be fixed shortly. Jason Zink :: MVP XNA/DirectX "Intellectuals solve problems, geniuses prevent them." - Albert Einstein Check out my game: Lunar Rift :: Dual-Paraboloid Mapping Article :: Parallax Occlusion Mapping Article :: Fast Silhouettes Article Check out our free online D3D10 book: Programming Vertex, Geometry, and Pixel Shaders |
||||
|
||||
 |
Myopic Rhino Staff Member since: The dawn of time
From: Temecula, CA, United States |
|||
 Posted - 4/17/2006 11:11:02 AM |
||||
| I fixed the links. Sorry about that. |
||||
|
||||
|
SaurabhTorne Member since: 1/31/2003 From: India |
|||
 Posted - 4/17/2006 12:04:25 PM |
||||
| cool articles. D/L link working fine.Never had the problem |
||||
|
||||
|
wolf XNA/DirectX MVP Member since: 1/8/2000 From: Carlsbad, CA, United States |
|||
|
Posted - 4/17/2006 3:46:54 PM |
||||
| cool article!!! - Wolf |
||||
|
||||
|
wolf XNA/DirectX MVP Member since: 1/8/2000 From: Carlsbad, CA, United States |
|||
|
Posted - 4/18/2006 1:12:29 PM |
||||
| Hey Jason, I just went again through the article. As you said the main problem with dual-paraboloid maps is the high tesselation level to achieve a decent quality. One of the ideas I had while looking at your source code is, to move more of the calculations in dual_paraboloid_terrain.FX into the pixel shader. Did you try this? I would think it does not make a huge difference, but does it make any at all? Another thing that is a general problem with this approach is the following statement in the pixel shader clip( IN.z_value ); This line kills early z-reject and hierarchical z-reject, so that the fill-rate necessary to write into the dpm is higher than necessary (because of overdraw) and maybe comparable to a cube map? ... never did the comparison. Is it possible to replace this statement by an if branch? Just a few ideas ... - Wolf |
||||
|
||||
|
Jason Z GDNet+ Member since: 2/4/2004 From: Royal Oak, MI, United States |
|||
 Posted - 4/18/2006 7:36:18 PM |
||||
| Hi Wolf, Thanks for the reply. The problem of requiring high tessellation is not really that big of a limitation as long as you can compensate for the small artifacts introduced in the generation phase. Really if you look at the two sample paraboloid maps from the article, and then how they look when applied to the sphere at the end of the paper there isn't really any noticeable distortion in the actual reflected images - it's just around the edges that is a problem. You are correct about the performance optimizations though - moving things into the pixel shader could help, but usually the more you do in the vertex shader the better - especially on lower end hardware. I used the clip command because originally I was going to implement both generation and accessing effects in PS1.1. I ended up running out of free time to work on it and decided to send it in as it was. However, I think the clip command is efficient if you are clipping large contiguous portions of a fragment which would be the case when rendering a fragment that is in the wrong hemisphere (front or back map generation). I am certain that there are many more optimizations that could be done on my effect files - I was trying more for clarity than efficiency. Perhaps you could give it a try and I'll compare the performance with yours and mine to see how much improvement there is... [smiles] Thanks again for the feedback - I am looking forward to hearing about any other ideas you might have as well! Jason Zink :: MVP XNA/DirectX "Intellectuals solve problems, geniuses prevent them." - Albert Einstein Check out my game: Lunar Rift :: Dual-Paraboloid Mapping Article :: Parallax Occlusion Mapping Article :: Fast Silhouettes Article Check out our free online D3D10 book: Programming Vertex, Geometry, and Pixel Shaders |
||||
|
||||
|
Dave Hunt Member since: 12/30/2002 From: Orlando, FL, United States |
|||
|
Posted - 4/19/2006 1:22:34 PM |
||||
| With the visual scheme I have (black background), the formulae are invisible in "non-printer-friendly" mode. Great article, though. |
||||
|
||||
|
jill_kitten Member since: 3/26/2008 From: Everett, WA, United States |
|||
 Posted - 3/26/2008 4:38:16 AM |
||||
| To have correctly mapped polygon edges, it seems apparent that you need to use a texture address modifying projection calculation [Prj matrix] instead of a vertex modifying view calculation. Also, it seems to me that you could put all that extended work into a single projection matrix eliminating the requirement that ALL end users must have a card that supports these specific procedural shaders [a problem I have come across with several users] and would cause the polygon edges to be mapped correctly. The only differences during the render are likely to be: -No procedural shaders needed -Use a specific projection matrix -When rendering for the negative surface, rotate the view position by Pi INSTEAD of changing how the scene is rendered [& maybe flip the y coord in the Prj Mtx]. Additionally, by some simple modification it should also be possible to render onto more of the outer edges of the surface which would also eliminate black lines from showing, and I would think it possible to even use the now standard cube rendering system to make it automatically address 2 specific faces with the right matrix and settings [again no procedural shaders needed]. |
||||
|
||||
| All times are ET (US) |
Last Thread Next Thread |
|
