[GSoC 2011 - Accepted] Dual Quaternion Skinning

Threads related to Google Summer of Code
mysterycoder
Google Summer of Code Student
Google Summer of Code Student
Posts: 169
Joined: Sat Dec 03, 2005 2:04 am

Re: [GSoC 2011 - Accepted] Dual Quaternion Skinning

Post by mysterycoder » Fri Jul 22, 2011 9:10 am

dark_sylinc wrote:Just make sure the new vertex declaration:
a. Takes care of memory alignment (16-bytes), not very strict seems some GPUs don't seem to be affected (may be that's not where the bottleneck is).
I'm a little confused about this statement. Isn't the vertex declaration for HW_VTF with LUT already not 16 byte aligned? From I understand, the second vertex declaration would be 56 bytes, so does this mean that padding should be added or am I perhaps misunderstanding?

Code: Select all

		//Now create the instance buffer that will be incremented per instance, contains UV offsets
		newSource = thisVertexData->vertexDeclaration->getMaxSource() + 1;
		size_t offset = thisVertexData->vertexDeclaration->addElement( newSource, 0, VET_FLOAT2, VES_TEXTURE_COORDINATES,
									thisVertexData->vertexDeclaration->getNextFreeTextureCoordinate() ).getSize();
		if (useBoneMatrixLookup())
		{
			//if using bone matrix lookup we will need to add 3 more float4 to contain the matrix. containing
			//the personal world transform of each entity.
			offset += thisVertexData->vertexDeclaration->addElement( newSource, offset, VET_FLOAT4, VES_TEXTURE_COORDINATES,
				thisVertexData->vertexDeclaration->getNextFreeTextureCoordinate() ).getSize();
			offset += thisVertexData->vertexDeclaration->addElement( newSource, offset, VET_FLOAT4, VES_TEXTURE_COORDINATES,
				thisVertexData->vertexDeclaration->getNextFreeTextureCoordinate() ).getSize();
			offset += thisVertexData->vertexDeclaration->addElement( newSource, offset, VET_FLOAT4, VES_TEXTURE_COORDINATES,
				thisVertexData->vertexDeclaration->getNextFreeTextureCoordinate() ).getSize();

		}
0 x
My Google summer of code 2011 topic: Dual Quaternion Skinning
My Google summer of code thread
My Google summer of code wiki page

mysterycoder
Google Summer of Code Student
Google Summer of Code Student
Posts: 169
Joined: Sat Dec 03, 2005 2:04 am

Re: [GSoC 2011 - Accepted] Dual Quaternion Skinning

Post by mysterycoder » Fri Jul 22, 2011 10:05 am

Just one more question. :)
In BaseInstanceBatchVTF::retrieveBoneIdx, the HWBoneIdxVec is built by indexing VES_BLEND_INDICES by the index of the largest blend weight. I'm not quite sure why it is doing that, perhaps to degrade models with more weights gracefully? So, how do you think that should be handled for the two-weight case?

Also, I think that in that function I should build a HWBoneWgtVec, since VES_BLEND_WEIGHTS is already being read there.
0 x
My Google summer of code 2011 topic: Dual Quaternion Skinning
My Google summer of code thread
My Google summer of code wiki page

mysterycoder
Google Summer of Code Student
Google Summer of Code Student
Posts: 169
Joined: Sat Dec 03, 2005 2:04 am

Re: [GSoC 2011 - Accepted] Dual Quaternion Skinning

Post by mysterycoder » Mon Jul 25, 2011 11:40 pm

mysterycoder wrote:In BaseInstanceBatchVTF::retrieveBoneIdx, the HWBoneIdxVec is built by indexing VES_BLEND_INDICES by the index of the largest blend weight. I'm not quite sure why it is doing that, perhaps to degrade models with more weights gracefully? So, how do you think that should be handled for the two-weight case?
Actually, I was able to figure out what retrieveBoneIdx was doing and I was able to write a version for two weights that outputs a vector of weights alongside the indices.
0 x
My Google summer of code 2011 topic: Dual Quaternion Skinning
My Google summer of code thread
My Google summer of code wiki page

mysterycoder
Google Summer of Code Student
Google Summer of Code Student
Posts: 169
Joined: Sat Dec 03, 2005 2:04 am

Re: [GSoC 2011 - Accepted] Dual Quaternion Skinning

Post by mysterycoder » Thu Jul 28, 2011 12:34 pm

I just pushed a new version with the two weight skinning. :D
So far the performance looks pretty good compared to the linear HW_VTF technique, but I haven't tried it with the bone LUT yet.
0 x
My Google summer of code 2011 topic: Dual Quaternion Skinning
My Google summer of code thread
My Google summer of code wiki page

User avatar
Mattan Furst
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 260
Joined: Tue Jan 01, 2008 11:28 am
Location: Israel

Re: [GSoC 2011 - Accepted] Dual Quaternion Skinning

Post by Mattan Furst » Thu Jul 28, 2011 9:13 pm

sounds great
0 x
it's turtles all the way down

mysterycoder
Google Summer of Code Student
Google Summer of Code Student
Posts: 169
Joined: Sat Dec 03, 2005 2:04 am

Re: [GSoC 2011 - Accepted] Dual Quaternion Skinning

Post by mysterycoder » Sat Jul 30, 2011 12:07 am

I just pushed the LUT materials for the two weight skinning and everything seems to be working.
The performance should be fairly acceptable, keeping in mind that with the jaiqua model, the polygon count is more than x10 that of the robots.

As the performance probably won't be acceptable, I think that it may be a bit pointless to add two weight support for standard VTF instancing, is that ok? or should I do it for the sake of completeness?
With regards to features, I think that this project is pretty much done based on what I laid out in the schedule. Now I need to work on documenting some things and doing the GLSL shaders for instancing and RTSS. Does that sound good?
0 x
My Google summer of code 2011 topic: Dual Quaternion Skinning
My Google summer of code thread
My Google summer of code wiki page

mysterycoder
Google Summer of Code Student
Google Summer of Code Student
Posts: 169
Joined: Sat Dec 03, 2005 2:04 am

Re: [GSoC 2011 - Accepted] Dual Quaternion Skinning

Post by mysterycoder » Sat Jul 30, 2011 9:32 pm

Ah GLSL support is so much nicer when you don't have to transpose matrices. :)
I just pushed the GLSL for dual quaternion with instancing. Onto GLSL for the RTSS dual quaternion skinning.
0 x
My Google summer of code 2011 topic: Dual Quaternion Skinning
My Google summer of code thread
My Google summer of code wiki page

User avatar
Mattan Furst
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 260
Joined: Tue Jan 01, 2008 11:28 am
Location: Israel

Re: [GSoC 2011 - Accepted] Dual Quaternion Skinning

Post by Mattan Furst » Sun Jul 31, 2011 4:04 pm

As the performance probably won't be acceptable, I think that it may be a bit pointless to add two weight support for standard VTF instancing, is that ok? or should I do it for the sake of completeness?
As far as I'm concerned you don't have to do it. But @dark_sylinc should get the final word on this. I just sent him a message asking him to answer this one.
0 x
it's turtles all the way down

User avatar
Mattan Furst
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 260
Joined: Tue Jan 01, 2008 11:28 am
Location: Israel

Re: [GSoC 2011 - Accepted] Dual Quaternion Skinning

Post by Mattan Furst » Sun Jul 31, 2011 4:18 pm

I just pushed the GLSL for dual quaternion with instancing. Onto GLSL for the RTSS dual quaternion skinning.
This might be a bit to late but please review my answer in http://www.ogre3d.org/forums/viewtopic. ... 25#p431292.
When I dealt with the same problem in HLSL hardware skinning there was a simple solution which was to declare the matrices column-row in reverse order. Instead of matrix[X]x[Y] declare them as matrix[Y]x[X]. Then reverse the multiplication order. Instead of matrix * vector, multiply vector * matrix.
I don't know whether this trick of defining the matrix in transposed form will work for GLSL but it should. You can add a new feature to RTShader::Parameter which will tell a parameter to write themselves to the shader script in the transposed format. and then activate it for GLSL shaders. This can save quite a bit of code.
0 x
it's turtles all the way down

User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
Posts: 4135
Joined: Sat Jul 21, 2007 4:55 pm
Location: Buenos Aires, Argentina
x 266
Contact:

Re: [GSoC 2011 - Accepted] Dual Quaternion Skinning

Post by dark_sylinc » Sun Jul 31, 2011 4:38 pm

mysterycoder wrote:I just pushed the LUT materials for the two weight skinning and everything seems to be working.
Cool!
mysterycoder wrote:the second vertex declaration would be 56 bytes, so does this mean that padding should be added or am I perhaps misunderstanding?
Yes
mysterycoder wrote: As the performance probably won't be acceptable, I think that it may be a bit pointless to add two weight support for standard VTF instancing, is that ok? or should I do it for the sake of completeness?
Do it for the sake of completeness. We could add "IM_USEONEWEIGHT" and "IM_FORCEONEWEIGHT" in InstanceManagerFlags.
The absences of this flag means the instancing technique should attempt to use as many weights per vertex as the original mesh supports. The former flag would use one weight per vertex when recommended (i.e. VTF), and the latter flag would mean all techniques are forced to one weight per vertex.

IM_USEALL should include IM_USEONEWEIGHT which is the recommended.

When "IM_USEONEWEIGHT" and "IM_FORCEONEWEIGHT" are both present, IM_FORCEONEWEIGHT will have precedence.
mysterycoder wrote:In BaseInstanceBatchVTF::retrieveBoneIdx, the HWBoneIdxVec is built by indexing VES_BLEND_INDICES by the index of the largest blend weight. I'm not quite sure why it is doing that, perhaps to degrade models with more weights gracefully?
Yeah, that was it. It is common practice when you're downgrading weight count to start by removing weights with lowest influence and then normalizing (so the sum is still 1, an assumption made by Ogre).

Cheers
Dark Sylinc

PS. Sorry for answering late. You can PM me or email me whenever you have more. It's hard for me to follow the entire thread to look for Instancing-related doubts.
0 x

mysterycoder
Google Summer of Code Student
Google Summer of Code Student
Posts: 169
Joined: Sat Dec 03, 2005 2:04 am

Re: [GSoC 2011 - Accepted] Dual Quaternion Skinning

Post by mysterycoder » Mon Aug 01, 2011 11:10 pm

Mattan Furst wrote:This might be a bit to late but please review my answer in viewtopic.php?f=13&t=63952&start=25#p431292.
Oh, thank you for the reminder, I had forgotten about that.
Mattan Furst wrote: I don't know whether this trick of defining the matrix in transposed form will work for GLSL but it should. You can add a new feature to RTShader::Parameter which will tell a parameter to write themselves to the shader script in the transposed format. and then activate it for GLSL shaders. This can save quite a bit of code.
I'll look into doing this, thanks for the suggestion. Unfortunately, I don't think that trick will work for this case, as I'm not really treating the matrix as a matrix. The first row represents the quaternion and the second row represents the dual part, so I don't really have any way to reverse the multiplication order. Right now defining the matrix in the opposite order, mat4x2 instead of mat2x4, then transposing it in the shader produces the correct result. But as you said, transposing it before sending it would probably prove much more ideal.
dark_sylinc wrote: Do it for the sake of completeness. We could add "IM_USEONEWEIGHT" and "IM_FORCEONEWEIGHT" in InstanceManagerFlags.
The absences of this flag means the instancing technique should attempt to use as many weights per vertex as the original mesh supports. The former flag would use one weight per vertex when recommended (i.e. VTF), and the latter flag would mean all techniques are forced to one weight per vertex.

IM_USEALL should include IM_USEONEWEIGHT which is the recommended.

When "IM_USEONEWEIGHT" and "IM_FORCEONEWEIGHT" are both present, IM_FORCEONEWEIGHT will have precedence.
I pushed a generalized version that should handle any number of weights and number of rows in the matrices. I also added the flags with the behavior you suggested. I still haven't done the VTF technique with more than one weight, but I'm going to work on that next. Right now, the shader still only supports either one or two weights because I didn't want it to turn into a huge shader, but it should be fairly trivial to add weights, assuming you have enough free texture coordinates.
0 x
My Google summer of code 2011 topic: Dual Quaternion Skinning
My Google summer of code thread
My Google summer of code wiki page

mysterycoder
Google Summer of Code Student
Google Summer of Code Student
Posts: 169
Joined: Sat Dec 03, 2005 2:04 am

Re: [GSoC 2011 - Accepted] Dual Quaternion Skinning

Post by mysterycoder » Wed Aug 03, 2011 8:41 pm

I've been looking at the situation with GLSL, and I think I understand it now. GLSL is normally column-major. When a matrix is defined, it is defined as mat[columns]x[rows], rather than [rows]x[columns] as in Cg. But, when Ogre sends the matrices using glUniformMatrix, it sets transpose to true, so that the matrices will be interpreted as row-major. This works fine for most matrices, you can just reverse the multiplication order. However, for my use case it is unsuitable. Even if it is interpreting the matrices as row-major, GLSL still indexes matrices by column. So for a dual quaternion, which would be defined as a mat4x2, accessing the first index would result in a vec2, rather than a vec4 as in Cg. I'm thinking that I actually need the original column-major behavior for this particular matrix.

From what I see, I have four options:
  • Define ACT_TRANSPOSE_WORLD_DUALQUATERNION_ARRAY_2x4, which would write the matrix in transposed fashion, so a mat2x4 could be used to store it.
  • Add a method to switch between column and row-major interpretation in Ogre's GLSL implementation.
  • Add a parameter to RTSS to transpose the matrix (effectively transposing it twice).
  • Instead of using a 2x4 matrix, send the dual quaternions as a array of float4s.
0 x
My Google summer of code 2011 topic: Dual Quaternion Skinning
My Google summer of code thread
My Google summer of code wiki page

mysterycoder
Google Summer of Code Student
Google Summer of Code Student
Posts: 169
Joined: Sat Dec 03, 2005 2:04 am

Re: [GSoC 2011 - Accepted] Dual Quaternion Skinning

Post by mysterycoder » Sun Aug 07, 2011 12:15 pm

I've just pushed a bunch of changes to the instancing. I added support for multiple weights for VTF and shader-based instancing. Unless there are some bugs, I think that should do it for the instancing support. :)

As for the GLSL support, I'm thinking that an array of vec4s would be the simplest and most efficient solution to this problem, though, I'm not sure how to approach the RTSS implementation. Do you think that is the best solution?
0 x
My Google summer of code 2011 topic: Dual Quaternion Skinning
My Google summer of code thread
My Google summer of code wiki page

User avatar
Mattan Furst
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 260
Joined: Tue Jan 01, 2008 11:28 am
Location: Israel

Re: [GSoC 2011 - Accepted] Dual Quaternion Skinning

Post by Mattan Furst » Wed Aug 10, 2011 8:51 am

@mysterycoder

Sorry for not replying I missed the question part.
I'm thinking that an array of vec4s would be the simplest and most efficient solution to this problem
I would agree.
sending the values as matrix 2x4 just creates to many differences between GLSL and HLSL implementation. using vec 4 means there doesn't need to be any difference in code between shader language. You are not using the matrix in the shader as a matrix, just referencing values in it.

Perhaps it would be best to separate the ACT_WORLD_DUALQUATERNION_ARRAY_2x4 parameter to two parameters. One carrying the array of regular quaternions the other carrying the dual quaternion.
0 x
it's turtles all the way down

mysterycoder
Google Summer of Code Student
Google Summer of Code Student
Posts: 169
Joined: Sat Dec 03, 2005 2:04 am

Re: [GSoC 2011 - Accepted] Dual Quaternion Skinning

Post by mysterycoder » Wed Aug 10, 2011 10:24 am

Hmm you're right, it would be better to handle it in a uniform manner across shading languages. There's no real benefit to storing the dual quaternion as a matrix, though now I have quite a few shaders to rewrite. :wink:

I'm not sure exactly how I would do it in two parameters instead of one because of the way in which gpu parameters are handled.

Right now this is how ACT_WORLD_DUALQUATERNION_ARRAY_2x4 is written:

Code: Select all

case ACT_WORLD_DUALQUATERNION_ARRAY_2x4:
	// Loop over matrices
	pMatrix = source->getWorldMatrixArray();
	numMatrices = source->getWorldMatrixCount();
	index = i->physicalIndex;
	for (m = 0; m < numMatrices; ++m)
	{
		dQuat.fromTransformationMatrix(*pMatrix);
		_writeRawConstants(index, dQuat.ptr(), 8);
		index += 8;
		++pMatrix;
	}
	break;
Do you think it would be too expensive (double the matrix decompositions, etc.) to iterate over the list of world matrices twice, once to build the quaternion, then again to build the dual part? Or should I find a way to somehow cache the results of one parameter to use in writing out the other?
0 x
My Google summer of code 2011 topic: Dual Quaternion Skinning
My Google summer of code thread
My Google summer of code wiki page

User avatar
Mattan Furst
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 260
Joined: Tue Jan 01, 2008 11:28 am
Location: Israel

Re: [GSoC 2011 - Accepted] Dual Quaternion Skinning

Post by Mattan Furst » Thu Aug 11, 2011 2:40 pm

Do you think it would be too expensive (double the matrix decompositions, etc.) to iterate over the list of world matrices twice
I see your point.

Given that one of the main focuses of any graphic engine is speed then yes I do think it will be too expensive.

From what I've seen he decomposition of a matrix to the normal component of the dual quaternion does not rely on the dual component quaternion and vice versa. In essence you can separate this code to 2 codes one extracting and writing the normal component and one the dual component and they will run at pretty much the same way.

However if you implement it this way it will mean that you will need to abandon the use of the DualQuaternion class in those lines of code, meaning you will have duplicate code. Without using this system you will have a shader in the array containing two types of information: A normal quaternion component and the dual quaternion component.

Either way will sacrifice a bit of code well written-ness (Sorry my English is failing me :? ).

I think that the solution of changing the definition to vector of float4 with twice the size is the better one as far as code maintainability. Having odd structures is better then having duplicate code.

The only reason I can see for changing my answer is if you think there is a real possibility that someone will want in a shader to have just the normal or just the dual component of a dual quaternion.
0 x
it's turtles all the way down

User avatar
Mattan Furst
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 260
Joined: Tue Jan 01, 2008 11:28 am
Location: Israel

Re: [GSoC 2011 - Accepted] Dual Quaternion Skinning

Post by Mattan Furst » Thu Aug 11, 2011 2:43 pm

Just to clarify, when I said "I think that the solution of changing the definition to vector of float4 with twice the size"
this means that the code

Code: Select all

case ACT_WORLD_DUALQUATERNION_ARRAY_2x4:
   // Loop over matrices
   pMatrix = source->getWorldMatrixArray();
   numMatrices = source->getWorldMatrixCount();
   index = i->physicalIndex;
   for (m = 0; m < numMatrices; ++m)
   {
      dQuat.fromTransformationMatrix(*pMatrix);
      _writeRawConstants(index, dQuat.ptr(), 8);
      index += 8;
      ++pMatrix;
   }
   break;
Stays the same. The only part in code which that needs to be changed is defining the is ACT_WORLD_DUALQUATERNION_ARRAY_2x4 as a float4 array. And the size of the array will increase from [number of bones] to [number of bones] * 2.
0 x
it's turtles all the way down

mysterycoder
Google Summer of Code Student
Google Summer of Code Student
Posts: 169
Joined: Sat Dec 03, 2005 2:04 am

Re: [GSoC 2011 - Accepted] Dual Quaternion Skinning

Post by mysterycoder » Sat Aug 13, 2011 7:00 am

Thanks for your guidance, I've switched to GCT_FLOAT4 for now, but I feel that the correct choice will become more clear once I can stabilize the GLSL implementation.

I've been working on getting the techinque to work in GLSL under RTSS. It doesn't feel like GLSL is used very often with RTSS. :P
A few things I've learned while working on it:

GLSL's linker is pretty flakey. I had problems with passing an array as an argument to a function, if the function is linked. If the function is included and not linked, it's fine.

Also, there aren't very many errors produced when using a program that is linked. To figure out what is really going on with a program, copy and paste linked functions into the program, then compile with cgc -oglsl programname.glsl

A shader can't assign to input variables such as normal or binomial, those that are automatically bound by Ogre. This is actually a pretty big problem from what I've seen because the lighting stages of RTSS depend on those input variables. Since a shader can't modify the parameters, the lighting stage will use the original vertex position and normals, which would normally be adjusted by the skinning shaders.
0 x
My Google summer of code 2011 topic: Dual Quaternion Skinning
My Google summer of code thread
My Google summer of code wiki page

mysterycoder
Google Summer of Code Student
Google Summer of Code Student
Posts: 169
Joined: Sat Dec 03, 2005 2:04 am

Re: [GSoC 2011 - Accepted] Dual Quaternion Skinning

Post by mysterycoder » Mon Aug 15, 2011 10:17 am

I've found it difficult to make progress with GLSL and RTSS, so I moved onto preparing the project for the end of the summer.

As for GCT_FLOAT4 vs GCT_MATRIX2x4, I decided to leave the type of the parameter as GCT_MATRIX2x4. However, I added a parameter to resolveAutoParameterInt in which you can specify the desired type for the parameter. Right now the RTSS technique defaults to GCT_FLOAT4 for both Cg and GLSL, but I may make it conditional in the future if there is a performance impact in the Cg shaders.

Then I moved onto fixing up the demos, I checked to make sure that they could run under both Cg and GLSL, in both RTSS and non-RTSS configurations (aside from the GLSL RTSS version of the dual quaternion demo).

Next, I plan on revisiting some spots where perhaps better doxygen documentation or comments could have been added. I'll also generate an actual thumbnail for the dual quaternion demo and update the demo videos with the changes spacegaier had recommended.

After these changes, I think the project will be pretty ready for release. If I have additional time, I'll continue to work on my GLSL issues. Is there anything else you would like me to do to prepare for release?

P.S.
mysterycoder wrote:GLSL's linker is pretty flakey. I had problems with passing an array as an argument to a function, if the function is linked. If the function is included and not linked, it's fine.
This seems to be resolved with the latest revisions of the nvidia drivers (version 280 series).

If you'd like to give the GLSL code a stab, I believe the generated shader should be correct after removing these lines from RTSS:

Code: Select all

	//add functions to calculate normal and normal related data in world and object space
	addNormalRelatedCalculations(vsMain, mParamInNormal, mParamLocalNormalWorld, internalCounter);
	addNormalRelatedCalculations(vsMain, mParamInTangent, mParamLocalTangentWorld, internalCounter);
	addNormalRelatedCalculations(vsMain, mParamInBiNormal, mParamLocalBinormalWorld, internalCounter);
0 x
My Google summer of code 2011 topic: Dual Quaternion Skinning
My Google summer of code thread
My Google summer of code wiki page

mysterycoder
Google Summer of Code Student
Google Summer of Code Student
Posts: 169
Joined: Sat Dec 03, 2005 2:04 am

Re: [GSoC 2011 - Accepted] Dual Quaternion Skinning

Post by mysterycoder » Sun Aug 21, 2011 9:08 am

I pushed a version where I've added the correct copyright notices and did a general cleanup on code formatting with a bit more documentation and comments. I also created a thumbnail for the dual quaternion skinning demo. Tomorrow is the pencils down date. I just wanted to double check, anything more you'd like me to do?
0 x
My Google summer of code 2011 topic: Dual Quaternion Skinning
My Google summer of code thread
My Google summer of code wiki page

User avatar
Mattan Furst
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 260
Joined: Tue Jan 01, 2008 11:28 am
Location: Israel

Re: [GSoC 2011 - Accepted] Dual Quaternion Skinning

Post by Mattan Furst » Sun Aug 21, 2011 10:29 am

@mysterycoder

The code looks good. I haven't been able to fix the problem in the glsl rtshader.

I have committed a fix for older machines. I forgot I checked your code using slightly different materials than you. I added vs_3_0 profile to the cg shaders and switch the delegate order between the cg and glsl so it will work on my machines.

There is one thing I noticed. When displaying the dual quaternion sample with rtshader activated the shadow rotates with the movement of the object instead of staying put relative to the direction of the light. This is defiantly something which used to work. I'm in the process of checking it out.
0 x
it's turtles all the way down

User avatar
Mattan Furst
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 260
Joined: Tue Jan 01, 2008 11:28 am
Location: Israel

Re: [GSoC 2011 - Accepted] Dual Quaternion Skinning

Post by Mattan Furst » Sun Aug 21, 2011 1:04 pm

I found the position where the light calculations become weird. It's occurs in changeset 2925 due to the change in the light position.
This effect is very match dependent on the position of the light. To see this effect the light needs to be above the helices and rather close by.

I think this is a problem with the RTShader light handling functions not with your code. If you change the light type from spotlight to point the coloring seems correct. I can't figure out whether this is a bug or a correct calculation of an improper setup. The math for this is a little bit beyond me. and as this is probably not in the dual quaternion code problem, out of the scope of this project.

I would suggest changing the light type to point for now.

Does the shader appear correct on your end. Perhaps it's a graphic card or a driver problem?
0 x
it's turtles all the way down

User avatar
Mattan Furst
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 260
Joined: Tue Jan 01, 2008 11:28 am
Location: Israel

Re: [GSoC 2011 - Accepted] Dual Quaternion Skinning

Post by Mattan Furst » Sun Aug 21, 2011 4:56 pm

Last update.

just found a bug in vtf and vtf hw 2 weights where you removed from the vertex deceleration the weight information that you were using in the shader. For some reason it still worked with OpenGL only had problem with DirectX. Fix is checked-in

Please check that everything on your side is checked in.

I think besides that it's a wrap.
0 x
it's turtles all the way down

mysterycoder
Google Summer of Code Student
Google Summer of Code Student
Posts: 169
Joined: Sat Dec 03, 2005 2:04 am

Re: [GSoC 2011 - Accepted] Dual Quaternion Skinning

Post by mysterycoder » Mon Aug 22, 2011 4:02 am

Mattan Furst wrote:I have committed a fix for older machines. I forgot I checked your code using slightly different materials than you. I added vs_3_0 profile to the cg shaders and switch the delegate order between the cg and glsl so it will work on my machines.
Looks good, thanks.
Mattan Furst wrote:just found a bug in vtf and vtf hw 2 weights where you removed from the vertex deceleration the weight information that you were using in the shader.
Awesome! thanks. It's unfortunate that I was only able to test this on linux.
Mattan Furst wrote:I think this is a problem with the RTShader light handling functions not with your code. If you change the light type from spotlight to point the coloring seems correct. I can't figure out whether this is a bug or a correct calculation of an improper setup. The math for this is a little bit beyond me. and as this is probably not in the dual quaternion code problem, out of the scope of this project.
Hmm... even after playing with the position of the light, the shadows seem to be ok on my computer. Though, perhaps I don't understand what you're talking about or maybe it's a driver issue? Could you upload a screenshot of the problem?
Mattan Furst wrote:I think besides that it's a wrap.
Great! I think so too. Everything on my side is checked is as well. Thanks again for the changes.
0 x
My Google summer of code 2011 topic: Dual Quaternion Skinning
My Google summer of code thread
My Google summer of code wiki page

User avatar
Mattan Furst
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 260
Joined: Tue Jan 01, 2008 11:28 am
Location: Israel

Re: [GSoC 2011 - Accepted] Dual Quaternion Skinning

Post by Mattan Furst » Wed Aug 24, 2011 5:05 pm

Just posted the final evaluation. Everything should be ok.

One last thing, before checking in the code to the main branch please give me a little bit more time to go over and QA it. I think there is a bug with the 2 bone instancing example. Plus I would like to try and get a better model for the demo. I'll try to get to it over the week end.
0 x
it's turtles all the way down

Post Reply