Archived

This topic is now archived and is closed to further replies.

Nukem

Rendering Q3 BSP Bezier Patches

Recommended Posts

I fully understand all the concepts of Bezier Patches but I am confused as hell about how to get them out of the BSP and render them. I have no clue about how to get the data out of the BSP all I know is that when I render BSPs currently I have an if statement in my engine for them so would I be rendering the data in that face? How does it work? As for rendering them after doing research on this(google + fourm search) I am even more confused then before. I read red book gamstrua(I probably get the spelling wrong) and they all do it different ways. All I know is I have to generate all the coords before they are rendered. But how are they rendered, points or lines? What is the best way to do this with Quake III I read that the actual engine only stores up to 3 patches in frustrums near it how would I do this? Could someone please help me out? Thanks nuke

Share this post


Link to post
Share on other sites
First of all, the book '3D Games' by Watt and Policarpo has an extensive section (and source code) on this very subject. It's not the most efficient method of rendering, but it works.

A face of type 'patch' (or whatever it's called) works like this. The first vert and number of verts fields point to a list of verts which are the control points. The size field tells you the number of control points in each direction. A Quake 3 .bsp patch face is actually (or can be) several patches, arranged so that they share control points along the edges. They are quadratic, so a single patch has 3 control points in each direction.

Imagine a grid of 5X5 control points. This would give you 2X2 individual patches. Draw it on a piece of paper and you'll see how it works.

To actually render the patch you need to compute the vertices from the control points. You should probably do this once at level load time and cache them. There are several methods - direct evaluation, forward differencing, central differencing, and de Casteljau subdivision are the main ones. I recommend de Casteljau because it's numerically stable and the edges will match up exactly.

For lod, you can skip rows and columns of vertices to create a coarser mesh - that's how '3D Games' does it. The more efficient way would be to store several index arrays, one for each lod, and choose one based on some error metric at run time.

'Hope that helps. Feel free to ask any other questions you may have.

[edited by - jyk on May 19, 2004 11:35:07 PM]

Share this post


Link to post
Share on other sites
Thanks im gona try to get that book ASAP. Ill try my library and if they dont have it barns and noble or amazon. In the ment time would it be possible for you to e-mail me the code in the book so I could at least look at that?

Thanks

nuke

Share this post


Link to post
Share on other sites
"In the ment time would it be possible for you to e-mail me the code in the book so I could at least look at that?"

I doubt the license permits distributing the code that way. But you shouldn''t have any problem finding the book.

Share this post


Link to post
Share on other sites