Excerpts from a Virtual Reality Researcher

Don’t Forget The Fundamentals

A big project I’m currently involved with is developing an out of core point cloud renderer for the vizHOME project.  This application enables viewing of LiDAR scanned homes within our C6-CAVE as well as the Oculus Rift and DSCVR system.  The application is fully functional and I’m at the point of optimizing it.  In working on optimizations for the application, I came across some “gotchas” that I had definitely overlooked.

Early on in the development, I decided at some point to work with std::list rather than std::vector to serve as a type of priority queue when rendering.  At the time, this was due to some issues with getting a sort to work correctly with a vector of pointers to objects. The problem had something to do with how the predicate for std::sort was being declared – check out the fun syntax for the now correct declaration:

bool nearDistSort(const VizHomePCD * const & a, const VizHomePCD * const & b);

I’ve recently discovered that working with std::list is a really really bad idea in the majority of cases.. Adding some profiling code to the project showed that basic functions within std::list like push_back and pop_front were eating a significant amount of program time, particularly when the list reached up to 2,000-3,000 elements.

The following blog post confirms the poor, poor performance of std::list vs. std::vector in the majority of cases:

List vs. Vector vs. Deque

Fundamental lesson #1: carefully consider what data structures from STL are really appropriate for your application – and in most cases prefer vector/deque over list.


In performing some code re-factoring and replacing an older math class (custom class a visiting professor wrote) with a newer and more widely-used math class (glm), I came across a case of very very poor naming of a function in glm..

It turns out that glm has two different length() functions.  If you call the length() function on a declared object, i.e.

glm::vec3 test(1.f, 5.f, 20.f)


The length() call here will always return 3, as opposed to the length of the vector test.  What?  The function is returning how many elements it holds rather than calculating the length.. glm also has a global function length(vector type) to calculate the actual vector length instead, i.e.


Calculates the correct length.

Fundamental lesson #2: don’t make any assumptions about what a function is doing, actually look at the code (if possible) before using the function.  And name your functions clearly (particularly when millions of people will be using them).

Having worked with C++ for over 15 years now, these small fundamental things can still easily go unnoticed and cause chaos without careful testing.

Fundamental lesson  #3: always profile your application.