Jump to content

  • Log In with Google      Sign In   
  • Create Account

Suen

Member Since 19 Feb 2012
Offline Last Active Feb 09 2014 04:26 PM

Posts I've Made

In Topic: FPS Camera

12 August 2013 - 11:06 AM

Suen,

 

I'm just going to throw a few things at you.  I think you may be confusing yourself.  I'd rename some of your variables like 'cameraTarget' should be 'cameraTargetPos' so you clearly identity a position VS a direction vector.  It's important not to get those confused.

 

For rotation, you can just easily make a rotation matrix and multiply that by your viewMatrix.

 

I'm not familiar with the glm library, but I saw a glm::rotate function that I believe makes a rotation matrix.  Then you can just do...

 

viewMatrix = rotationMatrix*viewMatrixAxes*camPosTranslation;

 

(or put rotationMatrix at the end) -- I can't remember what way OpenGL multiplies it's matrices.

 

Good luck!

Jeff.

Well changing to this actually solved the problem, thanks. Thanks for the name-change suggestion, you're right that I shouldn't confuse a position with a vector, my bad.

 

But honestly I'm still wondering what exactly I'm doing wrong in the original code. I'm merely changing the position of my camera's reference(target) point. To rotate it I switch to a spherical coordinate system, alter the correct element of the coordinate and switch back to the cartesian coordinate system, and then calculate the look/forward vector. The camera position remain the same but since the camera's reference point now has changed (cameraTargetPos-cameraPos) should result in a new vector which should be rotated by some amount. Am I thinking this wrong?

 

edit: changed the name of cameraTarget to cameraTargetPos in my first post as suggested.


In Topic: SSE2 Integer operations on Vectors

11 March 2013 - 05:59 PM

I'm not really sure there's any value to this excercise. As soon as you get to mul_epi32(), you're going to shrug your shoulders, and then give up (otherwise you're going to produce an abomination in code). Take it as a hint you may be approaching this this wrong....  A SIMD-optimised, integer Vec2/Vec3 SOA implementation is of no use to anyone. In practice, you're more likely to use the integer ops when converting a 16bit colour to floating point RGBA, or calculating offsets into floating point data arrays, etc. Generally speaking, bitshifts, bitwise operators, extract, and addition/subtraction tend to be most useful of the integer instructions (combined with a few cvtps_epi32/cvtepi32_ps ops here and there). Multiplication is there if you need it, but chances are, you probably don't!

 

I'm more than likely not going to use something like in a serious project as there already great VecX-libraries out there that get most of the job done (and I wouldn't be surprised if many of them are SIMD-optimized and even if not the compiler might do it for you). It's just me playing around mostly but I have to admit using Vec2 and Vec3 with SIMD does give a headache, might explain why it's not all that useful :P


In Topic: SSE2 Integer operations on Vectors

11 March 2013 - 04:45 PM

If you know you will only operate on X values, rearrange your data:

struct Data {

    int * xValues;
    int * yValues;

    const unsigned numValues;


    explicit Data (unsigned valueCount)
        : numValues(valueCount)
    {
        xValues = AlignedAllocate(sizeof(int) * valueCount);
        yValues = AlignedAllocate(sizeof(int) * valueCount);
    }

    ~Data () {
        Free(xValues);
        Free(yValues);
    }
};

Data d;
// TODO - initialize data elements

__m128i changes = _mm_set_epi32(5, 6, 7, 8);

for (unsigned i = 0; i < d.numValues; i += 4) {
    __m128i values = _mm_load_si128(reinterpret_cast<const __m128i *>(&d.xValues[i]));
    __m128i result = _mm_add_epi32(values, changes);
    _mm_store_si128(reinterpret_cast<__m128i *>(&d.xValues[i]));
}
This will operate on 4 values at a time, with fewer cache misses than any other option, and probably ideal throughput given sufficient compiler optimizations.

 

Yep was simply thinking of doing this, going in that direction now. I will be operating on the Y-values but much less in comparison. Might as well change my design from AOS to SOA while it's still possible as it fits better with the way SIMD works.


In Topic: SSE2 Integer operations on Vectors

11 March 2013 - 04:00 PM

Sounds like you're looking for SoA to/from AoS conversion (SoA = Structure of Array, AoS = Array of structures)

Note the conversion has a cost, so it depends on all the operations you're going to do to see whether it is worth it.

 

See _MM_TRANSPOSE4_PS's code as an example of how to efficiently convert from AoS to SoA and back (designed to work for 4x4 matrices though)

 

Vector2* ar = CacheAlignedAlloc<Vector2>(SIZE);

//Some values are set for ar here....

__m128i v0v1;
__m128i v2v3;
__m128i v4v5;
__m128i v6v7;
__m128i sse2 = _mm_set1_epi32(5);
    
for(int i=0; i<32; i=i+8)
{
    v0v1 = _mm_load_si128((__m128i*)&positions[i]);
    v2v3 = _mm_load_si128((__m128i*)&positions[i+2]);
    v4v5 = _mm_load_si128((__m128i*)&positions[i+4]);
    v6v7 = _mm_load_si128((__m128i*)&positions[i+6]);
    _MM_TRANSPOSE4_PS(_mm_castsi128_ps(v0v1), _mm_castsi128_ps(v2v3), _mm_castsi128_ps(v4v5), _mm_castsi128_ps(v6v7));
    v0v1 = _mm_add_epi32(v0v1, sse2);
    v3v4 = _mm_add_epi32(v3v4, sse2);
    v5v6 = _mm_add_epi32(v5v6, sse2);
    v7v8 = _mm_add_epi32(v7v8, sse2);
    _MM_TRANSPOSE4_PS(_mm_castsi128_ps(v0v1), _mm_castsi128_ps(v2v3), _mm_castsi128_ps(v4v5), _mm_castsi128_ps(v6v7));
    _mm_store_si128((__m128i*)&positions[i], v0v1);
    _mm_store_si128((__m128i*)&positions[i+2], v2v3);
    _mm_store_si128((__m128i*)&positions[i+4], v4v5);
    _mm_store_si128((__m128i*)&positions[i+6], v6v7);        
} 

Ended up with this, haven't checked it's performance yet but it does look like a bad solution :/


In Topic: Ray tracer - perspective distortion

28 December 2012 - 09:13 PM

The above was fixed by tweaking some of the values (for now at least). I've hit another problem (unrelated to the topic) but I'm not sure if a whole new thread is needed for that as I've created this thread. Either way I'll give it a try:

I'm trying to render triangles. For the moment I just tried rendering one triangle using a geometric solution (inefficient but but it will have to do for now as I'm just experimenting). I create a triangle consisting of three vertices, then perform a ray-triangle intersection by checking first whether the ray intersects the plane which the triangle lies in and then whether it lies within the triangle or not. The code for this is below along with the code that renders my scene.

The problem I have is that the z-values seem to be flipped when I translate my triangle. If I transform the triangle from it's model space to the world space by a simple translation (no orientation involved) I expect +20 in the z-axis to bring the triangle closer to the camera, yet the result is that my triangle is placed further away from the camera. Using -20 brings the triangle closer to the camera. I thought my matrix transformations might be at wrong here so I specified the coordinates of the triangle's vertices in it's local space (model space) with different z-values to see if I would get the same result and I did.

 

Update: After going through my code again I noticed I was calculating the constant D of the plane equation wrong in my triangle intersection code. It should be D = -(N*V) where N is normal of plane and V is any of the triangle's vertices. I forgot to add the minus sign to it. It works as it should now.
 


PARTNERS