Aressera

• You shouldn't be allocating memory within a function like in LineInterHull, it's not necessary and slow. Just rearrange your test so that you merge both loops into one, and hence no need to cache the intersection data.
• Pass your vectors by const reference rather than by value.
• the line in MakePlane should be *d = -Dot( setnorm, point ). This is because the plane equation is defined as: a*x + b*y + c*z + d = 0, where (a,b,c) is the normal and d is the plane 'distance', so d = -(a*x + b*y + c*z)

you might be interested in some of the work being done on real-time sound propagation at UNC:

http://gamma.cs.unc.edu/GSOUND/ (my work)

http://gamma.cs.unc.edu/research/sound/ (other work)

I mostly use Visual Studio and Codelite. Codelite's code-completetion is very powerful and there are some features that are hard to resist, but this IDE is not getting much recognition as it should be, it's also actively developed by a couple of developers. And some plugins are developed by communty, like Zoom Navigator in the screenshot. A sample screenshot of codelite and visual studio side-by-side. I just hope more people use codelite and contribute to this project.

 

http://i.imgur.com/pokfrMr.png

That Zoom Navigator looks pretty nifty.

Tesselate your quads into smaller triangles with sides that are near equal. I'm not aware of any better way, that's just how graphics hardware works.

You're better off not using any trig functions and using transformation matrices instead, try this:

Vector2 v = (mousePosition - spritePosition).normalize();
Vector2 w = { v.y, -v.x };

Matrix2x2 m =
{
v.x, w.x
v.y, w.y
};

This should produce proper rotation if your sprite has a rotation of 0 degrees when facing down the X axis. Swap the columns if 0 degrees is facing down the Y axis. You can then take that matrix and use it for the upper-left 2x2 section of a standard 4x4 identity transformation matrix to get a matrix that can be sent to graphics hardware.

What it's doing is computing the rotated x axis (the vector v), then computing a vector perpendicular to v (the vector w) using the 'perp' product (2D cross product analogue). This forms the basis for a rotated coordinate system which can be directly converted to matrix form.

As for your original question, the inverse tangent is a way of computing one of the acute angles of a right triangle with a hypotenuse slope of (DeltaY / DeltaX), where DeltaX and DeltaY are the lengths of the legs of the right triangle. If you invert the expression, inv_tan(DeltaX / DeltaY) gives you the other acute angle. Basically it converts a slope (Dy/Dx) to an angle relative to the X axis. The regular tangent does the opposite, converts an angle to a slope (rise over run).

Since there is no official math library for OpenGL like there is for DirectX, I expect that most people either roll their own (my choice) or find an API-agnostic vector math library.

In my renderer, the base material class is called Material and it contains a set of MaterialTechnique objects that describe particular ways that an object can be rendered (i.e. forward rendering, depth-only, deferred g-buffer pass, etc.). Each MaterialTechnique contains an ordered list of ShaderPass objects that totally define all inputs to the shader for any number of passes.

The ShaderPass is probably the most important class in the engine. It contains a handle to a shader program resource and provides methods to make bindings between shader input variables in the shader program and shader input values (vectors, matrices, constant buffers, vertex buffers, textures). This system allows the ShaderPass to persistently verify that all shader inputs match the corresponding variable types in the shader source code. The ShaderPass even contains all vertex data - it has bindings from shader vertex input variables to vertex buffer objects. This seemed like a rather bizarre design decision but it makes sense if you think about it (vertex buffer data layout is dependent on the shader).

The result of storing vertex data in the ShaderPass class is that classes like StaticMesh end up just being a pointer to a Material and an index buffer.

At render time, a ShaderPass and an index buffer is given to the renderer. The renderer iterates over the bindings contained in the ShaderPass for both constants (uniforms), textures, and vertex attributes, and then submits those bindings to the graphics API. It then uses the index buffer to draw vertices from the bound buffers.

_______________________________________________________________

Most importantly, the bindings contained in a shader pass also indicate a usage enum (i.e. VERTEX_POSITION, LIGHT_POSITION, MODELVIEW_MATRIX, etc). This enum allows the shader writer to tag each shader input with a type of usage for that variable. If a binding is marked as a dynamic input, the renderer can optionally provide input values (constants/textures) based on scene state for the binding's usage. For instance, a LIGHT_POSITION shader input would cause the renderer to find the closest light to the object being rendered and submit its position to the rendering API. This system is really flexible and handles everything from model view and projection matrices to dynamic shadow and environment maps. Since many shader inputs depend on the dynamic scene state, this system defers input value binding until render time using automatically provided rendering state information.

I haven't really put much effort into a shader permutation system yet though... that's a future project.

Here's how my engine handles this, I haven't been able to come up with anything else that's any more flexible or simple.

The classes which abstract the main interface to the graphics API:

• DeviceManager - Enumerates all available 'devices' i.e. OpenGL, DirectX 10, DirectX 11, etc
• GraphicsDevice - implements a graphics API interface (i.e. OpenGL), creates a context for the particular device.
• GraphicsContext - main interface which handles GPU object creation (textures, buffers, shaders, etc), as well as submitting draw calls/state changes to the API. Also handles window system interaction. I have an OpenGLContext subclass and will soon have a DirectX10Context, and later others.
  • Call context->createTexture2D( image, texture format...) and like methods for other types to create context GPU objects from generic data.
  • Call context->draw( vertex buffer, index buffer, shader program ) to draw stuff.

These interfaces provide a way to get access to an underlying API in a uniform manner. Since all APIs wrap hardware functionality for buffers, textures, and shaders, there ends up being a common set of abstractions for different hardware data types:

• Texture - virtual interface for interactions with the texture system. Handles 1D, 2D, 3D, and cube textures and any other common texture parameters. Implemented by OpenGLTexture which provides the OpenGL implementation for the texture, including any API-specific data (GLint texture ID, for example).
• HardwareBuffer - virtual interface for vertex buffers, index buffers, and constant buffers. Provides buffer memory mapping, read/write access. Implemented by OpenGLHardwareBuffer.
• Shader -  virtual interface for shader creation. Takes source code and shader type/language (vertex/fragment, glsl/cg/hlsl), then compiles it. Implemented by OpenGLShader.
• ShaderProgram - virtual interface for shader programs. User attaches Shader objects to the program and then link them. Allows users to access the input variables for the linked shader program. Implemented by OpenGLShaderProgram.

In practice it is a little tricky to define good interfaces for these classes, but it can be done. All of these classes are wrapped in reference-counted smart pointers.

I believe at least some portion of the new functionality is probably available through OpenGL extensions... though I might be wrong about that. But yeah, the state of OpenGL sucks on mac.

Edit: oops, I guess not much after seeing that 10.8 OpenGL profile...

I'd say it looks like half the normals have the opposite direction from what you want, which would explain why nothing you do seems to work (since half of them will always be wrong). Check your terrain loading/normal calculation code, or perhaps the model itself could have bad normals?

Here's a faster version for computing barycentric coordinates, adapted from Ericson's Real Time Collision Detection book:

Vector3 computeBarycentricCoordinates( const Vector3& v1, const Vector3& v2, const Vector3& v3, const Vector3& point )
{
	Vector3 e0 = v2 - v1;
	Vector3 e1 = v3 - v1;
	Vector3 e2 = point - v1;
	
	Real d00 = math::dot( e0, e0 );
	Real d01 = math::dot( e0, e1 );
	Real d11 = math::dot( e1, e1 );
	Real d20 = math::dot( e2, e0 );
	Real d21 = math::dot( e2, e1 );
	Real inverseDenom = Real(1) / (d00*d11 - d01*d01);
	
	Real v = (d11*d20 - d01*d21) * inverseDenom;
	Real w = (d00*d21 - d01*d20) * inverseDenom;
	Real u = Real(1) - v - w;
	
	return Vector3(	u, v, w );
}

You could calculate the barycentric coordinates of the point you are interested in and then use the barycentric coordinates to weight the vertex values.

The barycentric coordinates of a point P for a triangle (v0, v1, v2) have the following relationship:

P = a0*v0 + a1*v1 + a2*v2

where (a0,a1,a2) are scalar weights for the vertices. For colors, etc just replace (v0,v1,v2) with (c0,c1,c2) to get the interpolated value at that point.

This even works for points outside of the triangle (which will produce negative weights), so it will handle your bounding box corners.

If you are interested in doing raw device I/O, check out the WASAPI. It is intended for use by modern professional audio applications, has low latency, and gives you access to all of the device's channels/sample rates/capabilities. It is the successor to waveOutOpen() and related functions on Vista+.

ASIO is another pro-level option supported by a lot of hardware drivers, but it isn't as widely supported as the above.

For my planet generator (in the planning stages right now), I'm going to use an icosahedron for the basic spherical subdivision to get a set of equilateral triangles which will each represent flat-ish terrain cells. These cells can then be subdivided recursively into 4 smaller equilateral triangles, then extruded to lie on the surface of the sphere (or something else, depending on elevation). You could theoretically use a quad tree for the triangle subdivisions though the math for the spatial subdivision will be a little weird (because you're dealing with triangles and not rectangles).

I'm not sure how it's going to work out in practice, but it's another idea for you to think about.

For rendering a planet at a distance (i.e. you can see the whole thing), it's probably best to just build a big vertex buffer for the whole thing because that won't take more than a few tens of thousands of triangles to achieve pixel-perfect curvature, then only switch to LOD terrain when the view gets really close to the surface (within 10-20 miles for earth).

One concept that I think is particularly useful is thinking about uniform/attribute/texture variable usages. Since the shader writer knows what the semantic usage of each input variable is, they can tag each variable with a usage enum value which specifies the semantic purpose of that variable (vertex position, normal, color, diffuse map, environment map, shadow map, model-view matrix, etc...). This could be done in some XML shader metadata format or something, accompanying the shader source.

At render time, the renderer looks at the input variables for a shader. If any of these inputs are not set (with constant uniform/texture values), the renderer can choose to provide the information needed from the current scene rendering state. For instance, tagging a shader variable as the model-view matrix tells the renderer that it needs to provide the proper transformation matrix for the current transformation stack being currently rendered. This prevents you from having to define certain hard-coded variable names as representing those semantic usages (ugh, fragile!). The shader's metadata provides this information, linking variable usages to scene data.

This technique can also be used to bind shaders to meshes/textures that are not otherwise related. The mesh specifies that it has a buffer of vertex positions, buffer of UVs, colors, etc, each with a usage enum. At render time, the renderer matches up the vertex buffers with the correct semantically-tagged shader attribute variables for those usages.

In addition, each usage enum object also contains an index value, indicating that it refers to the i'th usage of that type. This can be done to allow things like multiple lights, multiple texture coordinates, or anything else that can be enumerated (probably not model-view matrices!). A shader for 2 point light sources would provide input variables for the usages (light position - 0, 1) and (light color - 0, 1). The renderer (which knows about the light sources in view) then can find the two most important lights and provide them to the shader automatically!