[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 » Sun May 29, 2011 12:59 am

I've gotten the dual quaternions exposed to the shaders now as a float2x4. To do this, I added a new type of gpu parameter named ACT_WORLD_DUALQUATERNION_ARRAY_2x4. When I tested it, everything seems to send correctly to the shader.

I also tested with a hastily converted dual quaternion cg shader, and there were some problems with the jaiqua mesh. I'm not sure if there is scaling or shearing in her animation, but when I switched to the robot mesh, things seemed to go much better. However, if I increase the number of models, one of the robots gets transformed very strangely. It was just a quick test though, to check that the auto parameters were working. I'll look at it in more detail in a little bit.
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 May 29, 2011 11:53 am

@mysterycoder
It's nice to see your already at the stage of testing the shader.

I haven't had time to compile your latest code but I believe that the main difference between jaiqua and the robot is that the jaiqua model uses more than one bone per vertex. If the problem you were referring to was especially apparent at the joints of the character then it's probably something about that.

I have just committed the changes I have talked to you about for the HS system. One thing you may want to note is the difference in implementation between cg and glsl due to the different matrix representations (row vs. column major). It took me quite a bit to figure this one out. For now I would just suggest to stick with cg . I have opened a thread to discuss this issue in http://www.ogre3d.org/forums/viewtopic.php?f=4&t=64943

P.S.
Running the RTSS sample in the sample browser changes the rtss to use glsl/hlsl as a target language instead of cg.
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 » Tue Jun 07, 2011 3:22 am

Thanks for the heads up about the matrices, I'll stick with Cg for now.

Just like you said, I accidentally was blending four weights rather than two for the jaiqua model. Everything seems to work fine with the model, but sometimes there is a small amount of popping. As I think I converted the shader correctly(the robot mesh seems to animate perfectly), I was thinking that either there was a small amount of shearing or scaling happening in the jaiqua model.

To test that idea, I looked into implementing the two-pass version of the dual quaternion shaders which would support the scaling and shearing. I noticed that the Ogre::Matrix4 doesn't seem to have anything explicit in it for manipulating with shearing values, only scaling. When I added an additional auto params for the scaling matrix, I noticed that I was doing some redundant calculation. Currently the auto param code looks like this:

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;
case ACT_WORLD_SCALE_SHEAR_MATRIX_ARRAY_3x4:
	// Loop over matrices
	pMatrix = source->getWorldMatrixArray();
	numMatrices = source->getWorldMatrixCount();
	index = i->physicalIndex;
	for (m = 0; m < numMatrices; ++m)
	{
		Vector3 scale;
		(*pMatrix).decomposition(0, scale, 0);
		Matrix3 mm;
		mm[0][0] = scale.x;
		mm[1][1] = scale.y;
		mm[2][2] = scale.z;
		_writeRawConstants(index, mm[0], 12);
		index += 12;
		++pMatrix;
	}
	break;
But, if you are using the two-pass shader, the transformation matrix is decomposed twice, once for the dual quaternion, and once for the scaling matrix. Do you think it is worth trying to find a way to remove this redundancy? and do you any ideas about the jaiqua model? (there is a slight popping near the joints fairly regularly)

Also, this is now getting into my finals week, so I'll start back up on the 13th as noted in my schedule.
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 » Sat Jun 11, 2011 5:51 am

But, if you are using the two-pass shader, the transformation matrix is decomposed twice, once for the dual quaternion, and once for the scaling matrix.
I'm not a mathematician but can't see how you can use the dual quaternion extraction to save time in extracting scale. The only thing I could suggest is for the second pass to prepare a function which only extracts scale instead of scale, translation and orientation.

For now I can't compile the code. My personal computer on which I'm used to do my compilations is down. I'll have an access to a computer on Sunday and I'll try to help from there. I'll also try to ask the artist in our company to prepare for you a simpler model for you to work and experiment on.

On a final note, Sudden "popping" is not quite what I'd expect if the shear transformation was missing. If that was the case I would expect a more consistent "gentler" form of deformation. I seem to recall that dual quaternion have a problem with 180 degrees or more rotations could It be something with that. Personally I would try to look at the extracted values of the dual quaternion component or the orientation quaternion of the bones and try to see if the values jump there and if so why. Again, I'll try to look more into it on Sunday.
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 Jun 11, 2011 11:38 am

Ah, that's a good point about the 180 degree rotation, I'll try implementing the technique with the accurate antipodal point testing.

Regarding the decomposition, rather than getting the scale factor from the dual quaternion itself, I meant sharing the results from the matrix decomposition that is used to build the dual quaternion. About getting a function that only decomposes scale, that is a good idea. If I can't figure out a way to share the results between the two cases, I'll do that.
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 » Sat Jun 11, 2011 8:23 pm

Just 2 more things:

I tried to talk to sinbad and check whether he has access to the jaiqua model or if he knows whether the model uses shearing transforms. He gave the following answer:
Hi Mattan,

I don't know if the model includes scaling / shearing, I do remember it had a few edge cases in it that turned out to be a good test for my exporters and shader skinning, that's one of the reasons I used it, but I think they were mostly around translations.

I don't have the original model anymore, it came with Softimage XSI as one of the example scenes but I don't have access to that anymore (plus they stopped targetting real-time modellers). You'll probably need to use a different model if you need the source.

Best regards
Steve
About the relaying scale data to the model. If you are only going to pass scale and not shear transformation data you might want to use a simple float 3 parameter instead of a 4x4 matrix. This is both to conserve memory bandwidth and to allow support for models with larger amount of bones.

Shaders using shader model 3 or less only have 256 float4 constant registers available to them. If you'll pass both the dual quaternion data and full scale matrix you will only be able to support models with around 42 (=256/(2+4)) bones at most. passing scale as a simple float4 you will be able to support around 85 (=256/(2+1)) bones.
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 Jun 12, 2011 1:53 pm

I have a new model for you to practice on. (See attached file).
The model is basically a long cylinder connected to 2 bones at each end: Bone01 and Bone02. If you twist one of them you can clearly see the candy wrap effect. I think it will be easier on you to work on this model then on others.

The model doesn't have any animations so you'll have to change control the bone positions yourself. Just remember to set the bones to manually controlled (Bone::setManuallyControlled()) and you should be good to go.
Attachments
spine.zip
(160.39 KiB) Downloaded 152 times
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 Jun 15, 2011 9:36 pm

Thanks for the spine model, it should be very useful for visualizing the candy wrapper effects.
It was actually very small compared to the rest of the scene, so I tried scaling it, but then I realized that I needed the two pass shader to support the scaling. So, I got the two pass shader working and was able to scale the model.

I also implemented the accurate antipodality handling (which just ended up being a single if statement) and the popping stopped with the jaiqua model, although it seems slightly strange to me still, so I'll keep looking at it as the project goes on.

As I am writing a few different versions of the shaders, it seems like it would be a lot more managable to split their parts into different functions because there are only fairly small differences between the shaders. Would there be a performance hit or anything else that would be prohibitive?

This stuff isn't in the repository yet, but I should have it in by tomorrow.
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 Jun 16, 2011 2:39 pm

@mysterycoder

It's good to see that you resolved the poping issue and are continuing with the development. I hope everything went well with your finals.

Specifically about the model I can ask our art guy to scale it up. How big do you need it?
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 » Fri Jun 17, 2011 6:40 am

The model is actually fine, its small size ended up being useful for testing the two-phase shader. If need be, I can also adjust it with MeshMagick.

I made a new commit that fixed lighting and added shadows and two-phase skinning.

When I was working on the lighting, I ran into a problem where the light colors weren't being correctly set, but that was because I had set default_params in the unified shader definition rather than the cg shader definition. Yet, in the original hardware skinning shaders, the default_params are set in the unified definition, I'm not sure how they managed that.

It turns out that the Matrix4::decomposition does provide the shearing components, it just doesn't expose them. It uses Matrix3::QDUDecomposition to decompose the matrix. So, to get the components I am just using that method directly.

I am defaulting the shaders to use the accurate antipodality handling. But it is trivial to use the fast method, I provide a different function that you can switch in the shader.

As it is, the dual quaternion shaders should be a drop in replacement for the skinning shaders in the SkeletalAnimation demo. Now I am working on converting the shaders to glsl and perhaps an option to switch between the shaders at runtime in the demo.
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 Jun 19, 2011 9:40 am

I've checked in the GLSL support. Whew, that was a bit of a nightmare to get working! :(

The GLSL shaders aren't the most efficient right now because I'm transposing the matrices in the shader, but I'm not really sure how to address this. I know I need to transpose because of a column vs row-major issue, but as it is, it seems like there should be a better way.

Unfortunately, I've been unable to get texturing to work with the GLSL shaders. Due to the higher version of GLSL used (newer than 1.2), constructs such as gl_TexCoord are deprecated. Currently, Ogre auto-assigns custom vertex parameters to certain named attributes in GLSL (in the newer versions of GLSL denoted by "in" rather than "attribute"). But, there doesn't seem to be a way to designate which variables to pass between shaders, something that would essentially be a user-defined gl_TexCoord. As such, I've been unable to get the texturing to work in the GLSL shaders.

So, aside from the texturing issue, I suppose I'm at the end of the second phase of this project. I would like to write the HLSL shaders now, but am unable to for a bit. My only development platform is linux right now because I'm having a few problems with my laptop. Although, from what I understand, the HLSL shaders are very similar to the Cg 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

User avatar
Wolfmanfx
OGRE Team Member
OGRE Team Member
Posts: 1525
Joined: Fri Feb 03, 2006 10:37 pm
Location: Austria - Leoben
x 1
Contact:

Re: [GSoC 2011 - Accepted] Dual Quaternion Skinning

Post by Wolfmanfx » Sun Jun 19, 2011 10:18 am

Hi,

You get texcoords in the vertex program like this
attribute vec4 uv0; // uv1....

And you pass data from vertex to fragment program via varying like
varying vec4 oUv;

and you have to declare in the fragment program
varying vec4 oUv; // as incoming data

the must match by name/type thats it.

This works for veriosn 1.2 (why do you require 1.4 which feature is there what you do not have in 1.2?)
0 x

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 Jun 19, 2011 11:17 am

@mysterycoder

If the GLSL is giving you a hard time let it go. It's not that important for now. The more important part is making it work in the RTSS, And some of the problems you encountered will be automatically dealt with as part of that system. Plus I can help you once you reach that stage of implementation. In any case even if you only make it work on cg it will be good enough. You're focus should be on implementing the technology, making it compatible for different shader languages should be a secondary priority.
The GLSL shaders aren't the most efficient right now because I'm transposing the matrices in the shader, but I'm not really sure how to address this. I know I need to transpose because of a column vs row-major issue, but as it is, it seems like there should be a better way.
This is a bit weird for me. In my experience GLSL and cg have the same row major representation and HLSL has the odd column representation. Check that your program doesn't include the definition "column_major_matrices true".

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.

But in any case, I would suggest moving on to the next stage of implementation.
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 » Sun Jun 19, 2011 11:06 pm

@Wolfmanfx
Thanks for the information. :)
I was under the impression that GLSL 1.2 didn't support branching, but I was incorrect. I've switched the shaders to 1.2 and I've got texturing working now.

@Mattan Furst
Hmm, that is strange. At first I was under that impression as well, but when I treated the matrices as the same way as I do in Cg, it produced an incorrect transformation. I don't have "column_major_matrices true" in my program definitions either.

But you're right, I should just move onto RTSS now. Time for the fun stuff. :D
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 » Tue Jun 21, 2011 1:11 am

In my schedule, I proposed that the RTSS implementation would follow this design:

A virtual parent class HardwareSkinningTechnique:
  • A subclass HardwareSkinningLBS that implements the already implemented Linear Blend Skinning
  • Add a new subclass HardwareSkinningDLBS that implements basic Dual Quaternion Linear Blend Skinning in RTSS
  • Add a new subclass HardwareSkinningDBLSTwoPhase that implements two phase skinning in RTSS
Looking at it again, I still think it is basically a good structure. Although HardwareSkinningDLBS and HardwareSkinningDBLSTwoPhase are so strongly coupled that I was thinking HardwareSkinningDBLSTwoPhase could have an instance of HardwareSkinningDLBS as a member variable and perhaps be a friend class.

What are your thoughts on the design?
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 » Tue Jun 21, 2011 7:17 am

@mysterycoder
In general I tend to be very aprehensive about over using inheritance. The code is prettier but becomes much less manageable over time.

Specifically about your case in question, Linear Blend Skinning, Dual Quaternion Linear Blend Skinning perform the same general function in very different ways. I would agree that those two implementations need to be in seperate classes both inheriting from a third class.

In the case of HardwareSkinningDLBS and HardwareSkinningDBLSTwoPhase both classes perform the exact same operation in almost the same way. The only exception to this is that TwoPhase implementation adds a bit of more functionality. What will happen if someone in the future will want to cover accurate antipodality handling. Should he then add 2 more classes HardwareSkinningDLBSWithAntipodality, HardwareSkinningDLBSTwoPhaseWithAntipodality. What about handling of scale without shear. This sort of explosion in the number of classes is usually a sign inheritance is overused.

Further more because of how RTSS works if you implement both in the DLBS and DBLSTwoPhase in the same class the user will be able to switch between them when needed with much less fuss.

My preferance would be to keep HardwareSkinningLBS and HardwareSkinningDLBS seperate. And merge the HardwareSkinningDLBS and HardwareSkinningDBLSTwoPhase classes.
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 » Tue Jun 21, 2011 12:27 pm

Thanks for your thoughts, I too am wary of inheritance. :)
That's why I was suggesting to use composition to expose the functionality of the regular dual quaternion skinning to the two-phase.

But, after reading what you thought and looking more at the the HardwareSkinningFactory, I definitely agree with you. So, I'll have a HardwareSkinningTechnique class that both the DualQuaternionSkinning and HardwareSkinning classes will inherit from. Then, the HardwareSkinningFactory will create an instance of the appropriate class in createInstanceImpl depending on the property set in the script.
HardwareSkinning will have the existing syntax:

Code: Select all

"hardware_skinning <bone count> <weight count>"
and DualQuaternionSkinning could have:

Code: Select all

"dual_quaternion_skinning <bone count> <weight count> <correct antipodality handling> <scaling> <shearing>"
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 » Tue Jun 21, 2011 9:31 pm

I'm not sure what you intended in your architecture concerning the HardwareSkinningFactory. In a resent changeset I added to Ogre, the HardwareSkinningFactory class now also has the ability to read a mesh and add to it's material information on the number of bones and weights. This removes the need for defining it in the material script per entity. This can be helpfull for both the linear hardware skinning (LHS) and the dual quaternion (DQHS) one. Furthermore there is no reason why the LHS and DQHS should ever both be created for the same render state.

For these reasons I would suggest having the HardwareSkinningFactory as the factory for both the LHS and DQHS. Creating them according to a material script definitions, or if those do not exist, according to a default setting (This will mean that both LHS and DQHS will need to have the same SRS type name). Further more I would suggest to unify the material syntax to the following form.

Code: Select all

hardware_skinning <bone count> <weight count> [skinning type] [correct antipodality handling] [scaling] [shearing]
You can look in the hardware animation sample of the trunk version for a use case example of what I mentioned.
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 » Sun Jun 26, 2011 2:10 am

Thanks for your help. I've pushed the initial version of RTSS support into the repository. :)
At first, RTSS was a bit hard to figure out as the error messages and crashes were a bit hard to decipher, but it certainly has begun to make sense.

Current limitations:
  • As of now, I believe the only way to get the dual quaternion skinning is to set it in the material script.
  • The SGXLib code is only in Cg for right now.
  • I still have to adjust the normal vector for scaling and shearing matrices.
I'm a bit confused as to how shadows are supported. There are a few methods for setting custom shadow passes, but I was under the impression that RTSS could handle generating the shadows as well. Why are the shadow caster shaders not done programatically like 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

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 Jun 26, 2011 8:59 am

Why are the shadow caster shaders not done programatically like the skinning shaders?
The simplest answer is that it was not thought of at the time. When first created (By Nir Hasson) the initial aim of the system was to allow to easily introduce new shader functionality to the regular rendering process, while not having to resolve to complicated Uber shaders. At the time nobody though how this will influence shadow generation. It didn't even become an issue until half a year latter when hardware skinning was introduced.

Even now the only stage where shadow shaders usually differ between one another is in the hardware skinning stage. I'm not completely sure changing the RTSS to support different shadow shaders is worth anyone's development time.
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 » Thu Jul 07, 2011 8:30 am

Just a quick progress update.
I've gotten the custom shadow casters working for Cg and GLSL with regular and two-phase varieties.
I was struggling with getting the GLSL version of the RTSS technique to work, and although I believe I am quite close, decided to move on for now.
Right now, I am writing a demo that highlights the difference between dual quaternion and linear skinning. I should have it up by tomorrow.
Sorry for the relative silence, but I have been working. :)
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 07, 2011 9:36 pm

Hmm... I've seemed to run into a bit of a design trouble. While I was writing the demo, I noticed that sometimes the dual quaternion skinning would be applied to an entity that had linear blend skinning specified for it in the material. It was a bug I hadn't noticed in HardwareSkinningFactory::createInstance.

I first set the skinning type in the createInstance method depending on the declaration in the material. Then this line is called which creates or retrieves the sub state renderer:

Code: Select all

//create and update the hardware skinning sub render state
SubRenderState* subRenderState = createOrRetrieveInstance(translator);
When it detects a type you haven't created a SubRenderState for, createInstanceImpl is called. createInstanceImpl creates an instance of either HardwareSkinning or DualQuaternionSkinning depending on the type of skinning set. However, regardless of the type of instance created, the same type of instance is returned for both skinning types. So even though the materials have different declarations, the same HardwareSkinningTechnique is returned. I tried to address this by retrofitting two skinning types onto the HardwareSkinningFactory, but I started running into some problems inside of RTSS.

I was thinking I could replace the createOrRetrieveInstance with sort of a little caching thing in the HardwareSkinningFactory itself instead of the SubStateFactory, so that it could handle both types, but I'm not sure. :?

Any ideas on how to fix this?
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 07, 2011 10:50 pm

I'm not really sure what you refer to as a caching mechanism please explain.

I'm not really near a computer where I can compile the code, but as far as I can feagure out you have the following options:
  1. Create a separate factory for dual quaternion and regular hardware skinning. This will mean will have to ensure you don't create 2 hardware skinning sub-render state for the same render state. It will also mean you will need to be more careful on code reuse.
  2. This is a tiny bit of a hack, but HardwareSkinningFactory::createOrRetrieveInstance(translator) ends up calling HardwareSkinningFactory::createInstanceImpl() for the actual creation of the instance. You can set up some variables in HardwareSkinningFactory in the createInstance() function then according to those variables create the correct type in the createInstance() function.
  3. Turn the hardware skinning sub render state into a pimpl type implementation and initialize the type of pimpl implementation when the render state is returned to you. I don't know why but personally I hate pimpls. It always seems like extra code where there shouldn't be any (http://www.gamedev.net/page/resources/_ ... impl-r1794). This system however has the advantage of having the ability to switch between hardware techniques without much trouble. Even after the sub render state has already been created and assigned to the render state.
  4. Implement all hardware skinning methods in the same class without inheritance. Very bad choice. especially as I can already see a need to extend the class with other skinning options.
[s]Personally I favor options 1 and 2. Option number 1 seems like better looking code but given how the RTSS is constructed I think the number 2 option will cause less trouble.[/s]
editted:
I really hate to say this but I think the 3rd (pimpl) option seems like the best bet. It is the least likely to cause you trouble. And will probably also be quite "design friendly".
Last edited by Mattan Furst on Thu Jul 07, 2011 11:20 pm, edited 3 times in total.
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 Jul 07, 2011 11:13 pm

It's funny that you mentioned supporting shadows in RTSS. Due to a project I'm working on in my company I realized I may need a system like that more than I thought. However if I do end up working on such a system it will in all probability be only after you finish with your project.

I am currently working on adding functionality to the instancing mechanism written by @dark_sylinc. (http://www.ogre3d.org/forums/viewtopic. ... 25#p432630). I understand that as part of your project you intend to implement dual quaternion with instancing in the same general area. I believe I can finish with most code changes by the end of next week. Would you still like me to hold off on merging my code until you finish your project?
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 » Fri Jul 08, 2011 2:19 am

I already using #2 of your suggestions right now. That's what I am running into trouble with. If I have two materials that both use RTSS's hardware_skinning, whichever technique the first material uses, the second will automatically use. This is because RTSS stores a pointer to the instance based on the type name. Since the HardwareSkinningFactory can only have a single type name, the second material will retrieve the technique used in the first material because they have the same type name. So, even though createInstanceImpl creates a different instance depending on skinning type, the retrieval of the correct instance is broken as is.

I agree that #3 does seem like the best idea, I'll go implement that. Thanks for the solution. :)

Yep, an RTSS solution for the shadows would be nice, there are a lot more iterations than I anticipated. If you decide to implement it later, I'll go back after the project is done and do a dual quaternion implementation.

Unless you feel it would prove particularly problematic, I have no problem with you merging your changes before hand as long as you feel that they'll be fairly complete. It'd probably be a good idea for me to implement it atop the most recent code. Thanks for your consideration.
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

Post Reply