Jump to content

  • Log In with Google      Sign In   
  • Create Account

RPTD

Member Since 16 Jun 2001
Offline Last Active Jun 21 2015 12:49 PM

Posts I've Made

In Topic: Pixel precise point rendering with GLSL has errors

05 January 2015 - 11:34 AM

That seems to work. At last for the errors cases I had it didn't score incorrectly anymore.


In Topic: What is better? TransformFeedback or OpenCL Kernel?

29 December 2014 - 01:51 PM

Interesting points. Just to clarify the update has to be done "intra-frame" so frame-spawning hacks are not possible at all. So the question focuses on direct calculate-then-render scenario. Everything else is too rigid and breaks anything except lab conditions.


In Topic: Matrix to Quaternion calculation instable

26 July 2014 - 06:28 PM

Sorry for not replying sooner but the forum failed to send me a notification about you having posted so I assumed nobody answered until I decided to still check back in case the forum soft is broken (as it is).

 

So to your post... I could be wrong but is this not the same as my version just written in a non-un-rolled version? Maybe I'm missing something but it looks similar to me.

 

 

Try this conversion method, it is the same one used in the OGRE engine. Note: totally untested in this form.

/// Create a new quaternion from a 3x3 orthonormal rotation matrix.
/// Quaternion = {a, b, c, d}, Matrix3D = column major
Quaternion( const Matrix3D<T>& m )
{
	// Algorithm in Ken Shoemake's article in 1987 SIGGRAPH course notes
	// article "Quaternion Calculus and Fast Animation".
	T fTrace = m.x.x + m.y.y + m.z.z;
	
	if ( fTrace > T(0) )
	{
		// |w| > 1/2, may as well choose w > 1/2
		T fRoot = math::sqrt(fTrace + 1.0f);  // 2w
		a = 0.5f*fRoot;
		fRoot = 0.5f/fRoot;  // 1/(4w)
		
		b = (m.y.z - m.z.y)*fRoot;
		c = (m.z.x - m.x.z)*fRoot;
		d = (m.x.y - m.y.x)*fRoot;
	}
	else
	{
		// |w| <= 1/2
		Index nextIndex[3] = { 1, 2, 0 };
		Index i = 0;
		
		if ( m.y.y > m.x.x )
			i = 1;
		
		if ( m.z.z > m[i][i] )
			i = 2;
		
		Index j = nextIndex[i];
		Index k = nextIndex[j];
		
		T fRoot = math::sqrt( m[i][i] - m[j][j] - m[k][k] + T(1) );
		
		T* apkQuat[3] = { &b, &c, &d };
		*apkQuat[i] = T(0.5)*fRoot;
		
		fRoot = T(0.5)/fRoot;
		
		a = (m[j][k] - m[k][j])*fRoot;
		*apkQuat[j] = (m[i][j] + m[j][i])*fRoot;
		*apkQuat[k] = (m[i][k] + m[k][i])*fRoot;
	}
}

In Topic: low sample count screen space reflections

03 August 2013 - 06:02 AM

 

I did now some experimenting by combining the broad-phase stepping from my screen-space with the narrow-stepping from the view-space. The rest is better in the narrow-phase but still not as clean as in the screen-space. I think though this problem is due to me currently using depth-reconstruction as I didn't yet switch back to hacing a full RGBF16 position texture in the gbuffer. And far away the differences in the depth value are so small that stepping fails to be accurate in the narrow-phase while in the view-space version the z-difference is precise enough. I'm going to change this once I have the position texture back in the gbuffer.

 

So right now I would say my screen-space version still wins in terms of overall quality once I have fixed the narrow-phase with using z instead of depth.

I used vs pos reconstruction too. It is supposed to be the same quality as a full-blown position buffer. This is why it is called reconstruction tongue.png

 

FYI: I've just tried Call of Juarez: Gunslinger, and they use SSR, and it is much worse than your or my version...

 

 

The problem is the lack of precision. Depth is calculated using a perspective division and most pixels on screen are not close to the camera with their depth value somewhere above 0.9 quickly approaching 1. The range of z-values mapping to the same pixel gets large quickly. With your reconstruction you obtain a sort of middle z-value midst in the range. Comparing this with the test ray doesn't do precision any good. So in most of the range of pixels in screen the depth difference is small although the z-difference is huge. Combine this now with stepping (reflectionDir / stepCount) and pair this up with 32-bit floats in shaders and their 6-7 digits of precision and you are up to a precision problem.


In Topic: low sample count screen space reflections

02 August 2013 - 02:27 PM

I did now some experimenting by combining the broad-phase stepping from my screen-space with the narrow-stepping from the view-space. The rest is better in the narrow-phase but still not as clean as in the screen-space. I think though this problem is due to me currently using depth-reconstruction as I didn't yet switch back to hacing a full RGBF16 position texture in the gbuffer. And far away the differences in the depth value are so small that stepping fails to be accurate in the narrow-phase while in the view-space version the z-difference is precise enough. I'm going to change this once I have the position texture back in the gbuffer.

 

So right now I would say my screen-space version still wins in terms of overall quality once I have fixed the narrow-phase with using z instead of depth.


PARTNERS