I don''t mind discussing my PhD in public at all (my promotor might, but he doesn''t know about these message boards hehe).

I''m doing it on Image Based Rendering - the art of using an image with depth information to generate arbitrary new views of the objects in the image.

The reason I''m still doing lots of vector math, is because I wanted to compare it to a technique called "Voxel Texturing", which was the subject of my master''s thesis. ( I still have it laying around somewhere in PDF format. )

The problem with it was, that it''s not perspective correct. Now I''m working on "Displacement Mapping", kindof an evolution of the ideas I had for Voxel Texturing, only more powerful, perspective correct, and with the potential for commodity hardware acceleration, because it can use a standard polygon pipeline.


Ps: Here''s the final fast version of my vector class. If anyone wants to test the speed, go right ahead! If you can beat it I''d like to know how of course.

class CVector3f{public:  // Fast ctors  inline CVector3f( ) : x(0), y(0), z(0) {};    inline CVector3f( float nx, float ny, float nz) : x(nx), y(ny), z(nz) {};    // Fast copy ctor  inline CVector3f( const CVector3f &v ) : x(v.x), y(v.y), z(v.z) {};    inline CVector3f operator+( const CVector3f &v1 ) const  {         return CVector3f( x + v1.x, y + v1.y, z + v1.z );  }  inline CVector3f operator-( const CVector3f &v1 ) const  {    return CVector3f( x - v1.x, y - v1.y, z - v1.z );  }  inline CVector3f operator*( const float scale ) const  {    return CVector3f( x * scale, y * scale, z * scale );  }  inline CVector3f& operator=( const CVector3f &v )  {    x = v.x;    y = v.y;    z = v.z;    return *this;  }  inline CVector3f& operator+=( const CVector3f &v )  {    x += v.x;    y += v.y;    z += v.z;    return *this;  }  inline CVector3f& operator*=( const float scale )  {    x *= scale;    y *= scale;    z *= scale;    return *this;  }  inline void Displace( const CVector3f &v1, const CVector3f &v2, const float scale )  {    x = v1.x + scale * v2.x;    y = v1.y + scale * v2.y;    z = v1.z + scale * v2.z;  }    float x;  float y;  float z;}; 

#pragma DWIM // Do What I Mean!
~ Mad Keith ~

Looks good. No need to prefix all the functions with inline though, if they are defined within the class body, they will automatically be inlined.

This is a really crap test,

the line:
vec1 = vec2 + vec3 * vec4;

was executed in a for loop 1000000 timesd

I just did some lazy timing of functions and...

times in milliseconds
function: vector =
time: 2709.462
hits: 3000000

function: vector *
time: 2471.946
hits: 1000000

function: vector +
time: 2471.261
hits: 1000000

Nothing to be particularly pleased with...

-Mezz

Okay some more tests now that I am back at work:

Using the operators is a LOT slower on my PentiumII here than using the "Displace" function. In fact, it''s twice as slow. The C-style functions are faster than using straight operators, but slower than using the "Displace" function.

Mezz - if you still want to have a "speed-battle" just post your vector class, and I''ll slot it into my test thingie.


#pragma DWIM // Do What I Mean!
~ Mad Keith ~

One thing I am thinking about: when you left out the destructor completely you gathered an "enormous" speed improvement. Hm, perhaps you get another speed "boost" by deleting the copy-constructor, too? You are just copying floats so a compiler generated copy constructor could do that. Huhah, I really dislike VC for forcing programmers not to write these methods because VC isn''t able to optimize them properly...

Bjoern

The funny thing with the destructor is that when I tried to reproduce the change, I couldn't find it again!
It doesn't get much slower when I add the destructor once again, it must be one of those funny "rebuild all" problems.

I'm going to have another look at it now.

[meanwhile, back at the mansion]

Okay, I've found it... and I've found the reason why I thought I had such a "massive" change. It's debug vs. release, as usual. The difference between C and C++ in Debug mode is HUGE, absolutely terryfying. The release build completely removes all of those differences it seems.

In Debug mode, some of those optimisations seem to make a lot of difference, while in Release, it always amounts to more or less the same execution speed.


#pragma DWIM // Do What I Mean!
~ Mad Keith ~

Edited by - MadKeithV on June 5, 2000 7:38:43 AM

dogs are slow?

... and in release mode the c++ operators are slower than equivalent c? What a strange world - this shouldn''t be this way... One question furthermore: do you use a "full" VC or a standard/campus edition? I am not sure but I have heard that only the "full" comercial edition of VC uses the full bootload of optimizations.

Bjoern
P.S.: I won''t accept that c++ operators like *= etc. are slower than c functions or data members... this really seems to be wrong... arghhh

No no no no, you understood me wrong:

Debug Mode:
C++ Slower than C, by a LARGE margin. Simple code changes make a lot of difference to C++ speed, but it never gets close to C.

Release Mode:
C++ Up to 10* faster than in Debug mode, and nearly always just as fast as C. Small optimisations seem to make NO difference to the exectution speed of the C++ though, not that it matters ''cause it''s already fast.

The only real killer still is accessing members when they are non-consecutive. I''m designing a way around that now.


#pragma DWIM // Do What I Mean!
~ Mad Keith ~

Huh, thats good news - I am glad I got it wrong the first time :-)

What do you mean by non-consequitive and performance penalties? And what do you want to do against it? (Is this the float x,y,z against float m_val[3] case?).

Bjoern