[PC] Devil May Cry 4

[revelation]

not to my knowledge. why would you think that?

EDIT:
Ah, hadn't even noticed. strange though considering i don't flip the vertices anywhere, computing directly from the bounding box information as given. i could easily remedy that i guess, but i'll have to take a closer look as to why that would be necessary, hmmm.

EDIT2:
Ah, ok, it appears the game uses the opposite culling flag value i use, which possibly indicates they use a different coordinate system than the default Left Handed coordinate system of direct3d that i am using. If this is the case then it is more than likely using a flipped x- or z- axis with respect to how i have it. For now i flipped the axis and culling flags accordingly to match those used in the game. At some point i guess i will have to go through and handle this appropriately. Thanks for catching that, heh. i am guessing this will affect all the games based on this engine.

[famesethu]

Hey great work surveyor,the Max script you made "Mod2Max.exe".....is awsome
I know this is just a prerelease.Will you please consider the removal of isolated vertices on your next version.
Thanks for the Great work......

[shadowmoy]

[quote="revelation"]

Code: Select all

struct
{
	// 0x00
	uint16    usId0 : 5;              // used as power of 2, tested against value indexed by usId1
	uint16    usId1 : 11;             // used as an index into a list of 32-bit (4-byte) values
	uint16    usMatId;                // material Id
	uint8     usFlag0x04[2];          // [0] - processing skipped if == 0
	                                  // [1] - tested against an unknown bitmask
	uint16    usFlag0x06;             //
	uint8     usFlag0x08[4];          // [2] - unknown value, &= 0xFE if (prev.endVertex0x0E + 1) != startVertex0x2A
	                                  // [2] - &= 0xBF, if 0 == tex4
	uint16    vertexCount0x0C;        // vertex count
	uint16    endVertex0x0E;          // end vertex - last vertex index used, compared to next object.startVertex0x2A
	// 0x10
	uint32    minVertex0x10;          // min vertex index
	uint32    streamOffset0_0x14;     // start offset for vertex stream 0 (in bytes)
	uint32    streamOffset1_0x18;     // start offset for vertex stream 1 (in bytes)
	uint32    startIndex0x1C;         // start index
	// 0x20
	uint32    indexCount0x20;         // index count - faces (indices - 2)
	uint32    uiBase0x24;             //
	uint8     unknown0x28[2];         // [0], [1] - indices into vertex declarations
	uint16    startVertex0x2A;        // start vertex, compared to previous object.endVertex0x0E + 1
	uint8     unknown0x2C[4];         // [0] - unknownData count, number of unknownData blocks assigned
	                                  // [1] - if 0x98 == file version, set to ((usFlag0x08[3] >> 1) & 0x0F)
	// 0x30
	uint32    unknown0x30 <format = hex>;    // seems to be unused, overwritten with unknownData start address
} objectData[fileHeader.objectCount];

ok some help :

Code: Select all

	uint8     usFlag0x04[2];          // [0] - processing skipped if == 0
	                                  // [1] - tested against an unknown bitmask

[0] is always 1 as i have seen
[1] seems to be THE MESH LOD LEVEL !!!!
lod0 = 255
lod1 = 512
lod3= 0xFc
so the mask could be 255 ?
tested on export and it seems clearly to be it, so surveyor please use this one to your mod2max exporter ...

[revelation]

The mask value tested against is usually 1 when stepping through the code. Looking at the differences between the versions of the head meshes for chris in RE5 this seems to be the only change between them. So if the 0 bit of the mask is set it appears you can use this as a test for the base LOD level. This is only from a quick glance after looking at the info you posted in the RE5 thread and relating it to the information i saw while debugging the benchmark executable for DMC4. Seems to pan out though, but you may want to check some more model files just to be sure.

Hope it helps.

[shadowmoy]

already tested on some complete models and on individual body parts (excella head, eyes and hair etc...), just have noticed some mesh duplicates on jill's hands that are exactly the same hight res model stored 2 times in the mod file instead of a lod0 and a lod1 lodmesh so it export it twice but it is normal after all...

[Surveyor]

normal bug is not a bug, the normals you import are dynamic normals based on the skeleton pose, they are recalculated dynamicly by the engine ,differently than max do (they need to be rotated by the inverse matrix of the vertex associated joint and normalized after.

Then how do you explain the normals behaving correctly inside the edit mesh scope and vanishing outside, The skeleton pose doesn't have anything to do with this, even when I was experimenting without the skin modifier this problem was there!!

the vertex duplication can also be explain easily, when welding vertices, the weld is based on vertex pos and not on uv mapping, so if you weld only this way , the rendering using vertex arrays and indices will completly fuck up the model mapping, the only way to fix it is to add degenerated faces or to duplicate vertices

I don't think so ... I made a quick check on the head model and guess what: the head model uses only 2 base textures so UV mapping isn't that different from an object to another. Look at the pic below, even with welding the mapping looks great!!

even more so with multitexturing where it is not always possible for the textures mapped to use the same uv coordinates

In this case, as for the majority of the models of DMC4, the uv coords are the same for all the maps except for the lightmaps which are mainly found in stages.

even on today's hardware there are not any cards i know of that have a recommended vertex batch size of anywhere near 49000+ vertices

Just try to imagine a head model with 49000+ verts, this would be way too detailed, which isn't the case of nero head, ninja gaiden 2 models for example are more detailed than those of dmc4 without even reaching this amount of verts (check out the ninja gaiden 2 thread).
I made a tool to quickly check vertex duplication and here's what I got:

original nero head model:
verts: 49613
indices: 12184

when eliminating all the duplicate verts, taking into consideration the position, texture coords, normals, binormals, tangents, bone indices and weights, I get this:
verts: 4511
faces: 5804

In terms of memory loss:
49613 verts x 32 bytes per vertex = 1587616 bytes on the video card
4511 verts x 32 = 144352 bytes only !!!! this is less than 10%

The question now is: why waste 1.5Mb on the video card for a model which is only worth 0.2Mb!!!
Another remark is that this difference isn't that big on body models, for example in nero body there is 12269 verts and after optimization I get 10798 verts which is 88% but still ....

Will you please consider the removal of isolated vertices on your next version.

This is one of the flaws of this program, these vertices aren't considered degenerate by max and thus not deleted, max says a degenerate face is a face that has more than 2 identical indices, the converter exports the data per object basis and thus can't know if a face has some duplicate indices so it makes them unduplicate, I'll try to hack this in the future release.

Ok poly, continuing from the last messages, here's a little explanation on how to fix the bone indices:
MOD files have something called bone groups, each object in the model is influenced by one of these groups, the bone group count is at position 40 from file start.
As said earlier, after you read the bone transforms, you read a bone table, the size is 256 bytes no matter how many bone you have you always read 256.
Then after you read the bone groups, a bone group is something like this:

Code: Select all

struct cBoneGroup
{
	unsigned int	uiBoneNum;	// bones in this group
	BYTE		*pBoneId;
};

// this part was already present in the code, I put it here to help you locate yourself in the human.cpp
// allocate memory for the bone tranforms and read them
m_pBoneTransform = new cBoneTransform[m_usBoneNum];
fread(m_pBoneTransform, sizeof(cBoneTransform), m_usBoneNum, pFile);

// read the bone table
fread(m_pBoneTable, 256, 1, pFile);

// read the bone groups
m_pBoneGroup = new cBoneGroup[m_uiBoneGroupNum];
for(unsigned int a = 0; a < m_uiBoneGroupNum; a++)
{
	fread(&m_pBoneGroup[a].uiBoneNum, 4, 1, pFile);
	m_pBoneGroup[a].pBoneId = new BYTE[m_pBoneGroup[a].uiBoneNum];
	fread(m_pBoneGroup[a].pBoneId, 1, m_pBoneGroup[a].uiBoneNum, pFile);

	// check if the bone count is greater than 32 in which case padding must be applied
	// this is a stupid hack, must pad correctly to x32 later
	if(m_pBoneGroup[a].uiBoneNum > 32)
	{
		// put a marker here
		printf("Hey that can't be !!!\n");
		return false;
	}
	fseek(pFile, 32 - m_pBoneGroup[a].uiBoneNum, SEEK_CUR);
}

For each object there is a bone group id, this id byte is located at position 45 for each cObject struct.

Now all is left is this:
for every object
for every vertex in this object
do this 4 times since we have 4 bones per vertex
BYTE cId = m_pVertex[the current vertex].bone[0 .. 3];
BYTE cTrueId = m_pBoneGroup[bone group to use].pBoneId[cId]

Notice that the bone table isn't used here!!! I'm too lazy to tell why so I'll leave this to you
I hope this helps you out

[revelation]

Thanks for posting the info, reminded me i never changed this information in the template files i posted. This is the matrix palette information used by the hardware skinning code in the vertex shaders. i also found that the cChild index in the joint information in the bone's mirror index, if it has one. Allows for appropriate handling of transforms for animations that can be flipped to work on either side and the like, or at least that is how it would normally be used, haven't tracked it fully through the code yet. i also hadn't gotten to using the transform data following the object definitions in accordance with this information. Do you make use of this at all?

[DMCdesigns]

Using Surveyor's old DMC4Model I've ripped this and I created a few bones to make the render pose. The proportions aren't the best because of the "pancake" effect.
Quick render using mental ray and maya 2009:

[Tosyk]

When I import a model instead of the bones creates are the points. How can I fix this?

[onionhead]

i have finally extracted the arc files with dmc4 extract but the file extensions are neither mod nor tex.
example:
d-mov049-xbox.wmv.0&²u

im thinking that its messed up or somthing. any one no wut to do. cuz mainly i just want to extract lady and trish. can someone plz post the mod file for lady and trish with textures. i could clean the models in max myself. Im only asking becuz im frustrated from not getting any of the stuff working at all.

[diablojin]

Hey Surveyor got a question with regards to dmc4extract...

Im currently trying to get it working, I use windows 7 if any help and avg flags it up as a trojan and if I ignore this windows will not open it?

Any help will be appreciated

Cheers

[onionhead]

my bad I exported the files instead of extracting it in RPGviewer. but now i have another problem when i use mod2max. there are no proper texture coordinates for trish and lady.

[Surveyor]

my bad I exported the files instead of extracting it in RPGviewer

I see you succeded to extract/view the models by now so there's no need to answer but let me say this:
The tools have been here for a while so if people already used them then there's no reason these tools won't work for you (unless you live on some other planet), just read carefully the HOWTOs, you must be missing something.

Im currently trying to get it working, I use windows 7 if any help and avg flags it up as a trojan and if I ignore this windows will not open it?

You know, I'm no fan of Microsoft products, they always suck in some way, even xbox 360 got the RROD!! As for the AVG, just disable proactive protection while you work with the converter, this perfectly works under XP. And by the way, you have some very nice modelling skills, I saw your works

Okay here's the updated version of the Mod2Max converter, this time texture coords work fine and I implemented the LOD flags so it's easier now to select the different LODs (useful in RE5 models). The generated scripts are larger in size and thus take longer to execute so be more patient.

Recently, I wanted to mess with DMC4 models and make "very" high res versions out of them (for some renders), Mesh Smouth under max does the job but I'll need to play with the edges a little, weld some parts, ...
The problem is that I don't want to loose the (PRECIOUS) skinning data (which would be the case since attaching meshes alters the skinning info) so I thought of splitting the generated scripts into 2 parts, the 1st exports the mesh data and when I'm done with mesh modifications the 2nd script comes to set the bones and skinning. If somebody has an idea about this then I'd like to hear it.

[Tosyk]

How to use your script to get the bones? I only get the points!

[Surveyor]

How to use your script to get the bones? I only get the points!

The converter creates points instead of bones because there's no orientation info for the bones, only position.
This is most frustrating in bones that don't have children, in which case there's no way to guess the bone's orientation so I preffered to make them all points.