Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 19 Oct 2012
Offline Last Active Feb 22 2015 01:14 AM

Topics I've Started

[Quake 3 BSP Rendering] Questions on Bezier Patches

22 December 2014 - 03:50 PM

Hey, everyone. I've been working on a BSP Renderer, using information given from here and here.
All in all, they're pretty solid, and seem to be the most common used references for the .bsp format out there (which I am aware of).

Anyway, I'm having some trouble wrapping my head around the following statement (from the second link, in the Faces section):

For type 2 faces (patches), vertex and n_vertexes describe a 2D rectangular grid of control vertices with dimensions given by size. Within this rectangular grid, regions of 3×3 vertices represent biquadratic Bezier patches. Adjacent patches share a line of three vertices. There are a total of (size[0] - 1) / 2 by (size[1] - 1) / 2 patches. Patches in the grid start at (i, j) given by:
i = 2n, n in [ 0 .. (size[0] - 1) / 2 ), and
j = 2m, m in [ 0 .. (size[1] - 1) / 2 ).

From what I gather, the author states that, since adjacent patches share a line of three vertices (with each patch having 9 control points each), we can use the (i, j) indices to find a total of 9 shared control points from the total number of vertices, which are then used for the triangulation.

However, I'm not sure what the "2n/m, n/m" bits actually mean in the bold portion. Can someone clarify this?

The current rendering implementation does the following for the patches:
else if ( face->type == FACE_TYPE_PATCH )
	const int subdivLevel = glm::min( 10, glm::abs( 10 - ( int )glm::distance( pass.view.origin, boundsCenter ) ) ); 
	const int controlStep = face->numVertexes > 9 ? face->numVertexes / 9 : 1;

	int i = 0;
	for ( int j = 0; j < face->numVertexes; j += controlStep )
		patchRenderer.controlPoints[ i ] = &map->vertexes[ face->vertexOffset + j ];
	patchRenderer.Tesselate( subdivLevel );
Note the controlStep: if we have more than 9 verts, we have to compensate and find 9 control points out of those vertices to send to the patchRenderer. As a result, we divide the number of vertices by 9, iterate through the loop, and use that quotient for the increment portion.

If we only have 9 verts, then all the vertices can be used, so we just increment by 1.

But I'm pretty certain that's the wrong way to go about it, since the control points are likely to be arbitrary and won't just be shared as multiples of 3 in the event that there is more than one region.


What is the proper way to attain the control points of the vertices, such that the amount of vertices is greater than 9,and given that the patchRenderer requires 9 control points exactly in order to tesselate the regions properly?

I appreciate any help.

What to know in order to write a mesh parser?

19 October 2012 - 11:33 AM

I'd like to learn how to write a Mesh Parser, using features in OpenGL from 3.3 and up (my drivers should support 4.3, I'm currently running 4.2).

The question is, I'm not sure what techniques/concepts would be good to understand first. I know how to write a binary search tree, if that helps - but maybe a QuadTree or even an OcTree would be more useful?

I've been studying from Learning Modern 3D Graphics Programming, and am currently at the Objects At Depth section.

Also what would be good to know is what kind of file formats are most common in the OpenGL world. Should I use blender to draw meshes, export the files, and render them in OpenGL? Is it possible and pragmatic to write a single mesh parser which would just render whatever kind of mesh I throw at it?

I'm aware of prewritten libraries such as GLMesh which help with this (though I'm not sure to what extent they do), but alas my goal is to learn so I'd like to avoid using something like that :3.