Hardware N-Patches in the rasterer
Disclaimer: This algy requires dedicated silicon and is virtually impossible now without software rendering, so dont bother reading this if your looking for something you can do in real time.
The concept is simple, instead of implementing N-Patches(aka PN triangles) early in the pipes(ie. splitting triangles + displacing them before they even reach the graphics card), implement them as late as possible, after everything has been transformed, while it is being drawn.
This can happen in 3 easy steps:
1) For each triangle: Substitute 2D normals & positions into the N-Patch equation(look here http://www.gamasutra.com/features/20...haines_02.htm)
make 3 more equations represending the edges of the triangle.
Derive all 4 equations with respect to Yand find the roots to find the maximum and minimum Y points on the screen that satisfy all 4 equations,
pass all raster lines between these values on to the next step
2) For each raster line: Derive equations with respect to X to find their roots, find all pixels of the triangle on the raster line and pass to next step
3) For each pixel lace the x and y coords of the pixel into the origional equation, find all values of z that satisfy it, then discard all values of z that dont satisfy all 3 edge equations. pass the z values in back to front order to the pixel shader(so that alpha blending works properly)
This algorithm would mean perfect N-patches and heavily reduce vertex requirements, however it would REQUIRE that correct and appropriate normals are passed from vertex shader to pixel shader
It may even be possible on current hardware, but as I know of no open source drivers, I cant tell.
I intend to attempt this on a software renderer, if anyone knows of an open source win32 renderer with lighting and a C/C++ raster loop, please e-mail me
Re: Hardware N-Patches in the rasterer
There is Crystal Space, but oooh, talk about heavy. It is rather interestingly modular, so I suppose you can implement your idea in a DLL for CS rather easily. I do not suggest you make CS your end all renderer... That renderer is very heavy and the support is very shifty. It is heavily documented, and the renderer itself is done in a modular way that should get you up and running very quickly. It is rather amusing to note that somebody wrote an ASCII renderer for Crystal Space.
Note it does not have a map maker, I was making one and then the CS maintainer pulled the entire windowing system I was using right out in favor of a new and totally different one. I suggest CS for testing your application. Download the current stable, test your idea, and dump it.
While you're at it, check out how the software renderer does the portal rendering... It uses planes and clipping regions to great effect.
[This message has been edited by 147-2 (edited 01-23-2004).]