Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 04 Nov 2012
Offline Last Active May 27 2016 09:29 AM

#4999762 VBO Pooling: Does it make sense?

Posted by on 10 November 2012 - 05:43 PM

Some ideas, most depending on the fact that there is at least some algorithmic relation between the objects

  • Using indexed drawing. Maybe you can have a "big" predefined VBO, and simply need to update the indices.
  • Using glBufferSubData(). Maybe some of the vertex data is the same, and some is not.
  • Is it a setup similar to animation? Animation can be greatly improved by using bones. Vertices are then attached to bones, and you only have to move a few bones. The shader will then compute the new vertices from the bones data, which is a much smaller set. The technique can be extended to arbitrary complex transformations, if the number of vertices is fairly constant but have a mathematical relation to a smaller subset of data.
  • Use a geometry shader to create the vertices you need.

Not everything is entirely accurate.
  • Indexed drawing is very useful, but you should be careful not to abuse it. In order for a pipeline stage to run efficiently most data should be cacheable. Abusing indexed drawing may actually backfire by causing a lot of cache misses in the vertex shader (obviously this will happen only for relatively large vertex buffers).
  • glBufferSubData is a double edged sword. It's really nice to be able to update parts of the buffer with one API call, but in many cases it actually ruins performance, because many synchronizations have to occur (basically you'll be stalling the hardware). The right way to do partial buffer updates is more complicated, and it involves using glMapBufferRange with GL_MAP_UNSYNCHRONIZED_BIT, while manually managing fences and of course doing it on two threads. Basically, avoid partial buffer updates whenever you can, and when you can't then try to split your buffers so you can. And if that fails then I don't envy you.
  • Bones are great. Use them whenever you can. They have their limitations, and some coding is required to do them right, but supporting them is practically a must.
  • If performance is your concern, avoid GS like the plague. There are some cases in which you won't loose performance by using GS. However, there are no cases in which it'll give you better performance than using the alternatives. This is mostly a hardware limitation, but (unfortunately) it's here to stay.
    One good thing to note about GS is that it makes your code neater, shorter and cleaner. So if you can't really be bothered by some annoying performance issues, GS is awesome.

#4999461 How to find the closest interception point?

Posted by on 09 November 2012 - 04:27 PM

Thanks for the correction. Yes, it seems I omitted (so conveniently) that asin is multivalued, so there can be up to two solutions.

However, using the law of cosines (instead of sines) fixes this inconvenience and also eliminates the need to use trigonometric functions.
Also, it'll be the solution with the relative velocity that has the larger magnitude (trivial).
Let's say <Va,Vba>/|Va|/|Vba|=cos(a)
So: Vba = sqrt(Va^2(cos(a)^2-1) + Vb^2) - Va*cos(a)

So still, no need to find the actual time of collision.

#4999093 How to find the closest interception point?

Posted by on 08 November 2012 - 07:28 PM

By interception you mean collision?
If so, then if the speed of B is given by Vb, then there's no closest, there's exactly one.
Their relative velocity must point against their initial relative distance, so all you need to find is its size and you're set.

Now you can apply the law of sines to get: Vba=Va*sin(a+b)/sin(b)
Where 'a' is the angle between the velocities Va and Vba. Applying the law of sines once more will yield: sin(b)=Va*sin(a)/Vb
Now computing the velocity Vb from velocities Va and Vba is just a matter of adding vectors.

#4998610 4x4 to 3x3+vec3 matrix conversion world/view/proj

Posted by on 07 November 2012 - 04:03 PM

There are many combinations with a 3x3 matrix and vec3 that will yield a projection matrix, so I'm just guessing here.
It's a long shot, but why won't you give it a try. You initialize your matrix to identity before putting stuff into it. Still do that, but also put zero into [3][3] and put -1 into [2][3] (if -1 doesn't work, try 1).

#4997791 Visualizing Perspective projection

Posted by on 05 November 2012 - 05:45 PM

Luckily for you, you don't need to visualize the 4D coords since you're working in RP^3.
If you're not into topology, then the easiest way to visualize the point is dividing by the last coordinate (assume nonzero) and treat it as a point in R^3, because points in RP^3 are equivalent that way. With this approach it's a bit hard to understand what the projection matrix actually does to points in RP^3, so you should work your way from bottom up, i.e. to derive the projection operation for an arbitrary projection plane in R^3 and see how to utilize the extra coordinate in RP^3 to make your equations "neat" (put them in a matrix).

Another way is to look at RP^3 as the set of all lines in R^4 that pass through the origin. What the projection matrix does, is just what any other matrix does, it rotates*scales*rotates those lines. Rotation is straightforward, scaling isn't. Scaling a set of lines in a singular way is like identifying subsets of lines (in a non-singular way you just pack them closer or farther apart).
For instance, if you have two different lines [x:y:z:w] and [x:y:z:w'] with w!=w', then scaling by [1,1,1,0] identifies these two lines. This correlates to projecting points in 3D space onto a plane, as many different points go to the same point on the plane.

Step 2, is pretty much like finding the intersection of the transformed lines with the hyperplane w=1, which results in a 3D point. But since we already identified some lines with others, we obtain points on some plane instead.

Also, a true projection matrix is indeed singular with a zeroed last column, as is yours. Projection matrices in graphics applications are a bit different, as they also compute the local coordinates of the point on the projection plane (up to the division factor) and preserve the depth information. However, these two operations have nothing to do with the projection per se.

#4997545 Multiple Render Target shader question.

Posted by on 05 November 2012 - 06:29 AM

The spec says that you cannot input to vs with interface block, and it makes perfect sense because vs reads the data from a buffer created by the api.
Same for fs, it outputs data to a buffer created by the api, hence no interface blocks.
Interface blocks connect only pipeline stages, with the only exception which is transform feedback (but the connection in this case is implicit).

Now that you matched all outputs to inputs it works. You could've also split the interface block into two blocks, and accomplish the same result.
Generally, using interface blocks is slightly better than just dumping all the variables into the global block, since it gives more structure to your code, but this is really your own choice.