<- 1  -   of 75 ->
^^
vv
List results:
Search options:
Use \ before commas in usernames
Edit history:
puelo: 2015-05-02 02:26:09 pm
Code:
	std::vector<float3> normals;
	uint32_t numNormals = fileHeader.sectionSizes[2] / 6; // 6 (3 short a 2 bytes) per Vertex
	for (unsigned int i = 0; i < numNormals; i++) {
		float3 normal;
		short x, y, z;
		inputFile.read(reinterpret_cast<char *>(&x), sizeof(x));
		inputFile.read(reinterpret_cast<char *>(&y), sizeof(y));
		inputFile.read(reinterpret_cast<char *>(&z), sizeof(z));
		x = _byteswap_ushort(x);
		y = _byteswap_ushort(y);
		z = _byteswap_ushort(z);
		normal.x = x / (float)0x8000;
		normal.y = y / (float)0x8000;
		normal.z = z / (float)0x8000;

		outFile << "vn " << normal.x << " " << normal.y << " " << normal.z << std::endl;
	}


Although _byteswap_ushort is only defined for unsigned shorts it should work for signed shorts as well (kinda checked this with manually swapping the bytes).
aha, okay... your normals have a magnitude of 0.5, not 1.0. Try dividing by 0x4000. That should do the trick.
I'm guessing this might work if you want to get picky with swapping normal shorts http://stackoverflow.com/a/2637138
The swapping is fine, that isn't the problem.
Dividing by 0x4000 fixed the magnitude, but it still looks off. I slowly get the feeling that it is no longer a problem of the normals alone.
Updated .obj: http://pastebin.com/RvGRq9xt

Screenshot:
Only other thing I can think of is if you aren't associating the correct normals with the vertex coordinates... it should always be the attribute after the position, though, which I assume is what you're doing. Do you think you could post the rest of your current code? Would be helpful to see what's going wrong.
there are still most certainly some weird normals, it looks like the normals are facing the wrong way on some faces (black faces in the render I made). not sure what is causing this, might be vertices being read in the wrong order, faces being read clockwise on some places and other way around in other places maby?
Edit history:
Aruki: 2015-05-02 03:00:40 pm
Oh, maybe it's a problem with triangle strip conversion? If you're converting triangle strips to triangles, every other face needs to have the vertex order inverted. That could certainly cause a problem like this if that's not being done correctly.

edit: ooh, yeah, it's definitely a problem related to vertex order. Turn on backface culling; a lot of the triangles are backwards. Should check your code for triangle strips + fans and make sure those are being imported correctly.
I did that for the triangle strip(peeked in your conversion script for that :p) - but could still be wrong, i check it again!
Code can be found here: https://github.com/KammererTob/dkcr_cmdl_to_obj/blob/master/cmdl_parser/main.cpp

Be aware. It is a total mess at the moment. Relevant code for faces (submeshes) starts at line 387.
It works! Had to reverse the condition for the reversal of the vertices in the triangle strip code. Is this blender specific? Because i used the code form your (Parax) conversion script for 3DS?
god I need to rewrite those maxscripts at some point.

No, I think my script is just reversed because in 3DS Max, for some reason array indices start at 1 instead of 0. So yeah, for a C++ program where they start at 0, doing it the other way around would be correct. How's the model looking now?
Like this:


Thanks to all of you for your help!
Sweet, looks very nice. Well done!
Thanks again! Btw: Is there an easy way to determine the object inside a CMDL file without rendering it? Finding models at the moment is just searching through a lot of cmdl file until i find what i am looking for.
If you're looking for an animated model, then it will have an associated CHAR file that contains a string name. You can search through all the CHAR files in the pak for the string you're looking for and then pull the CMDL ID out of the CHAR.
Edit history:
puelo: 2015-05-02 03:16:26 pm
Ah good to know. Thanks!
What format do you prefer or suggest when i want to start working on animations? Because .obj is not capable of doing it. I though about fbx, because there exists a SDK.
I actually don't know, I haven't gotten to working with animations myself. I'm probably going to use FBX but I'm not sure if there's a more suitable format. If you find one let me know.
I'm emitting FCurve constructors in a Python script for ANIM conversion ATM... That makes it blender-specific of course..
COLLADA would probably be the best "standard" format for representing ANIMs though
This is probably enough of an example to get you started:
https://gist.github.com/jackoalan/72a62f320dbebb52c66d
I'm pretty sure the ANIM format in DKCR is completely different from MP1 though.
Is there no longer a bitstream?
No idea how it's different specifically, I just recall hearing a lot from Retro in interviews and such that they made tons of changes to the animation system in DKCR.
ah, they probably mean the dynamic blending and IK systems.. i betcha not much in the ANIMs themselves changed
west furnace access why
Quick question, is there a way to see the exact dimensions of a model(how tall it is, how wide it is, ex)? I'm doing a project and I would like to know the dimensions of the visor pickup from prime 2 so I don't have to guess when making it.
Edit history:
Aruki: 2015-05-07 03:23:59 pm
0.98607725m x 0.9378154m x 1.646288097m

(dimensions of the model bounding box)