XeNTaX

It looks like a lot of tools have support for kinect.

Does yours support non-human models? lol

The contents of this post was deleted because of possible forum rules violation.

The Noesis Kinect implementation supports mocap on the NI/NITE skeleton, and it supports mapping that mocap skeleton to any skeleton. I've used it with non-humanoid characters before.

SC5 files will load in the next version of Noesis, whenever I get around to publishing a build. The only reason the files aren't accepted by Noesis is because they changed the NMD marker to 4E 4D 44 2E instead of 4E 4D 44 03. You can hex edit the 03 to 2E and Noesis will load it fine as-is. It won't load materials correctly though, which isn't surprising, I never completely figured out the material data in SC4 or T6.

MrAdults wrote:The Noesis Kinect implementation supports mocap on the NI/NITE skeleton, and it supports mapping that mocap skeleton to any skeleton. I've used it with non-humanoid characters before.

SC5 files will load in the next version of Noesis, whenever I get around to publishing a build. The only reason the files aren't accepted by Noesis is because they changed the NMD marker to 4E 4D 44 2E instead of 4E 4D 44 03. You can hex edit the 03 to 2E and Noesis will load it fine as-is. It won't load materials correctly though, which isn't surprising, I never completely figured out the material data in SC4 or T6.

Oh thanks mr adults, I'm gonna try ^_^

The contents of this post was deleted because of possible forum rules violation.

Is there a way to determine whether weights look right in preview mode? (vertex weights I guess, or however other ways bone weights may be implemented)

the main thing to do is manually move a bone in noesis and see if the deformations look right. I did not see a way to see vertex weights tho you could assign them as colors to test it visually.

What I like to do is assign a procedural animation to the model (check the commented out code that does this for Bullet Witch), that way all I have to do is hit play after the model loads to check that the weights are all working. Or, like chrrox said, you could visualize them by assigning vertex colors based on the weight values, but that could be a little bit of work to do nicely.

Formats that like to store their ascii characters in 2 bytes.
Cleanest way to deal with these?

Are the first two bytes FE FF (or FF FE)? If so, it probably uses UTF-16 encoding (not that this really helps with your question).

Actual models Call of duty games series not support in future?
Sorry my bad english =)

Dinoguy1000 wrote:Are the first two bytes FE FF (or FF FE)? If so, it probably uses UTF-16 encoding (not that this really helps with your question).

Nope. I think that's only used as a standard that's only really useful when sharing your files with others.

I think with formats like these, their engine would parse all strings the same way, so if they had japanese or chinese characters (or anything that was stored in 2 bytes) they don't need to parse them any differently.

finale00 wrote:

Dinoguy1000 wrote:Are the first two bytes FE FF (or FF FE)? If so, it probably uses UTF-16 encoding (not that this really helps with your question).

Nope. I think that's only used as a standard that's only really useful when sharing your files with others.

I think with formats like these, their engine would parse all strings the same way, so if they had japanese or chinese characters (or anything that was stored in 2 bytes) they don't need to parse them any differently.

Keep in mind that those bytes aren't required, and many programs won't add them to begin with when saving UTF-16 files. Another way to tell is if, in lots of the byte pairs (specifically ones corresponding to text in a language that uses the Latin alphabet), one byte (the same byte across all the pairs; I can't remember for sure whether it'd be the high or low byte) is null.

Yes, that's what Unicode is designed to do: if an application supports Unicode, it automatically supports all characters included in Unicode (well, this is a gross oversimplification, but no one should be using Unicode tools that require them to separately add support for e.g. character combining).

Yeah, you're describing unicode strings that don't happen to use anything in the extended character range. You should be able to load them in as unicode strings, and if you wanted you could then decode as something like UTF8 and it should work fine. (as long as they really aren't using any extended range characters)

Hmm, not sure how to describe this issue I'm having.

Here's a visual example:



The left is what I see.
The right is what I'm supposed to see (by disabling face culling)

The faces are drawn "inverted" I guess, so I'm seeing the back of it instead of the front (or however it is termed).

Usually when I just want to flip the front and back, I just multiply the x value of each position by -1.
Which gets the job done. I could probably just say "no face culling", but that's not a real solution.

The faces are stored as triangle lists, so I just commit them using the TRIANGLE constant.
Some of the models show up as expected, others are "inverted" as shown. There might be a flag that tells me "ok invert them". Maybe.

Is there a way to "invert" the faces without explicitly multiplying x-coords by -1?