Hey, thanks for sharing. I've finally gotten around to watching the vid and poking around the code. I have messed around with ray tracers from others and haven't been able to break it down into consumable bytes
. I have a couple of questions if you are up for the challenge.
WarriorMario wrote:(getting 'interactive framerates' and near to the 30 FPS on the CPU )
How did you get that framerate? SIMD? Multi-threading? Both?
I've tried using SSE using the "as-is" layout of Vec3 ( using alignas(16) to properly align the structs ) and it was still pretty slow. I used std::async with multiple thread counts and it does help, but still nowhere near 30 ( I didn't actually test the framerates using these methods, but it was choppy ).
The next step was to restructure it so that four rays would be cast at a time. This works very well. I get around 25 fps single threaded and about 40 using std::async with multiple threads. The only problem I'm having is dealing with the cases where some rays hit and some rays don't. For instance, if I'm checking one of the spheres and say two of the rays hit the sphere, but the other two rays hit the back wall, I'm having troubles combining the results so that I can tell which objects were hit.
Any help would be appreciated.
Just to clarify:
Code: Select all
for( int i = 0; i < m_spheres.numSpheres; ++i )
{
const Vec3p mSpherePosition( m_spheres.position[ i ].Load() );
const __m128 mSphereRadius( _mm_load_ps1( &m_spheres.radius[ i ] ) );
const auto mHitMask = RaySphereIntersection(
mSpherePosition, mSphereRadius, mCamPos, mRayDirection, mRayLength );
const auto mHitMaskI = _mm_castps_si128( mHitMask );
const auto res = _mm_movemask_ps( mHitMask );
if( res != 0 )
{
hitIndex = i;
}
}
if( hitIndex != -1 )
{
for( int i = 0; i < 2; ++i )
{
// The mRayLength holds the lengths of the four rays so mHitPoint are the four points of
// intersection
const auto mHitPoint = mCamPos + ( mRayDirection * mRayLength );
const auto mLightPosition = mLightPositions[ i ];
const auto mLightRayDelta = ( mLightPosition - mHitPoint );
const auto mLightRayDirection = Normalize( mLightRayDelta );
auto mLightRayLength = Dot( mLightRayDelta, mLightRayDirection );
// If any of the spheres occlude the light
bool occluded = false;
for( int i = 0; i < m_spheres.numSpheres; ++i )
{
// Vec3p is a struct with three __m128 members ( X, Y, Z ).
// When constructed with a single __m128 member, the first three elements are
// Swizzled/Shuffled so that X = {xxxx} Y = {yyyy} Z = {zzzz} the fourth SIMD element is
// ignored
const Vec3p mSpherePosition( m_spheres.position[ i ].Load() );
const __m128 mSphereRadius( _mm_load_ps1( &m_spheres.radius[ i ] ) );
const auto occMask = RaySphereIntersection(
mSpherePosition, mSphereRadius, mHitPoint,
mLightRayDirection, mLightRayLength );
const auto res = _mm_movemask_ps( occMask );
occluded = res != 0;
if( occluded ) break;
}
if( occluded == false )
{
const Vec3p mSpherePosition = m_spheres.position[ hitIndex ].Load();
const auto mNormal = Normalize( mHitPoint - mSpherePosition );
const auto mDot = Dot( mNormal, mLightRayDirection );
const auto mD = _mm_max_ps( _mm_setzero_ps(), mDot );
const auto &sphereColor = m_spheres.color[ hitIndex ];
Vec3p mSphereColor(
Vec4( sphereColor.y, sphereColor.z, sphereColor.w, sphereColor.x
).Load() );
finalColor = finalColor + (
Vec3p( mLightColors[ i ].x * mSphereColor.x,
mLightColors[ i ].y * mSphereColor.y,
mLightColors[ i ].z * mSphereColor.z ) * mD );
}
}
}
See, here's what I'm confused on. Even if this was x86 code, you don't do any comparisons on which object was hit first. The spheres are pretty much laid out in back to front order. So even if there are multiple collisions, you are relying on the fact that the last sphere checked that collides with the ray is going to be the sphere you use for your color calculations.
Unfortunately, even knowing this, I don't know where to go from here to check for closest collisions and what info I would need to carry over. The hitIndex isn't going to help here.
Using the current code, the render looks like the pixels are 8x8 blocks.
If you think paging some data from disk into RAM is slow, try paging it into a simian cerebrum over a pair of optical nerves. - gameprogrammingpatterns.com
