25 to Life: Reading models, indices issue

[dblF]

Hi everybody

Me and my friend we're making a tool to edit/create new .DBL game archives for 25 to Life. Now we're trying to figure out the models and the issue I have is that the indices I'm reading never display the model properly. I'm exporting the model as an obj file and it doesn't look normal. I'm attaching the screenshot of what it looks like.

First of all the triangles don't look right at all but what's even worse is that some edges are completely messed up. There is a py script out there that can view the models and they look just fine if you export them into OBJ through that script, but that's all it can do ----export the models. We're making a full on editor that can already work with textures and we're planning to make the tool that will cover the whole spectrum of the archives, so you will be able to make your own maps even.

 

So when I make the OBJ file out of the data I have the indices are not the same as in the obj file that I get when I export the model through the aforementioned py script. I'll also attack 2 files and the source Chunk which is the chunk#3 stored in the .DBL archive. I have no experience in programming models whatsoever so I'm really at a dead end here.

 

I'm certain that the indices I read are the right indices because I debugged the py script and the source indices it has on the input are exactly the same that I got. The issue is I don't relaly know what to do with em and my guess is they obviously have to be processed somehow because what I'm doing now doesn't work right. I'm also gonna provide the code that I came to that handles the vertex ordering.

 

Both OBJ files are in the zip archive that I'm allso attacihing to this post.

 

for( INT m = 0; m < pSomArray->meshes[i].somHeader[SOM_NUMSUBMESHES]; m++ ) {
			iAssignedVertexes += pSomArray->meshes[i].submeshes[m].meshData[MESH_STRTINDICE];
			
			for( INT ind = 0; ind < pSomArray->meshes[i].submeshes[m].meshData[MESH_NUMINDICES]-2; ind++ ) {
				if( ind & 1 ) {
					sprintf( pLine, "f %i\\%i\\%i %i\\%i\\%i %i\\%i\\%i\n",
						iAssignedVertexes+pSomArray->meshes[i].submeshes[m].indices[ind], 1, 1,
						iAssignedVertexes+pSomArray->meshes[i].submeshes[m].indices[ind+2], 1, 1,
						iAssignedVertexes+pSomArray->meshes[i].submeshes[m].indices[ind+1], 1, 1 );
					fputs( pLine, pOBJFile );
				}
				else {
					sprintf( pLine, "f %i\\%i\\%i %i\\%i\\%i %i\\%i\\%i\n",
						iAssignedVertexes+pSomArray->meshes[i].submeshes[m].indices[ind], 1, 1,
						iAssignedVertexes+pSomArray->meshes[i].submeshes[m].indices[ind+1], 1, 1,
						iAssignedVertexes+pSomArray->meshes[i].submeshes[m].indices[ind+2], 1, 1 );
					fputs( pLine, pOBJFile );
				}
			}
		}
}

 

!ak74.zip MeshChunk.zip

[diegozmei]

Xentax  And zenhax   i'm sorry  noesis script .DBL Files yes Durik256   fmt_DBL.py? 

[Durik256]

yep, I once made a plugin for dbl for this game, on xentax

[dblF]

yeah that one called fmt_DBL.py is what I have, I'm looking to order the vertexes properly if anybody knows how the indices are manipulated it'd be cool , just an explanation. The script feeds the indices into the noesis api , the indices its feeding are the raw indices that I'm getting also , but behind that I have no idea what's happening to them and that's exactly the most mportaint information

[dblF]

Tne there is the 3D Object Converter, when I export the AK74 through that program the vertex ordering is also different to both mine and that from the fmt_DBL.py script, yet it still looks fine

[dblF]

I tihnk i have an idea of what might be causing the problem, is there any way to convert the given array of indices to a list of triangles? Assumed it's a triangle strip, how would you go about converting it? I couldn't find anything on that,, only the opposite

[diegozmei]

i'm sorry XeNTaXTools Legacy github not 25 to life PS2/PC <DBL Files YES Disney Bolt Durik256 AND RobTheWrecker Chicken Little 
Chicken Little Blender fmt_DBL Noesis fixed? models LEVELS map NPC Characters wtf

[h3x3r]

Yep, it uses triangle strips. Ask user "shak-otay" he has some tri-strip snippet in c++. Or check his source code of hex to object tool.

[diegozmei]

fmt_DBL Noesis V0.1 Durik256 Just use a filesharing sites (like  MediaFire ) to upload it, then post the links here or post it on the "models and Textures Notepad++ 😞💪 

25 to life Pc DBL Files  closed  👋download  XeNTaX No💔 YES👍

https://www.mediafire.com/file/jroky5jsxraznye/fmt_DBL.zip/file

[shak-otay]

Guess dblF has his answers already, 6 weeks later.

If 'no', here's the link to tri strips generating code.

Didn't check it now; Noesis swaps indices, btw.

(The source of hex2obj is not public; other than that of Make_Obj, what was meant assumedly.)

edit: added build_strips() snippet there

Edited October 31 by shak-otay

[Durik256]

On 10/31/2024 at 1:23 AM, diegozmei said:

fmt_DBL Noesis V0.1 Durik256 Just use a filesharing sites (like  MediaFire ) to upload it, then post the links here or post it on the "models and Textures Notepad++ 😞💪 

25 to life Pc DBL Files  closed  👋download  XeNTaX No💔 YES👍

https://www.mediafire.com/file/jroky5jsxraznye/fmt_DBL.zip/file

This is one of the first versions of the plugin, it is not fully developed. And as far as I remember, I removed it from public access on xentax and asked not to distribute it on the network.

[dblF]

On 10/31/2024 at 8:37 AM, shak-otay said:

Guess dblF has his answers already, 6 weeks later.

If 'no', here's the link to tri strips generating code.

Didn't check it now; Noesis swaps indices, btw.

(The source of hex2obj is not public; other than that of Make_Obj, what was meant assumedly.)

edit: added build_strips() snippet there

Hi appreciate the snippets but I couldn't put them to good use unfortunately, I can't grasp the idea behind how would you go about ordering indeces, the indices within the DBL are as follows (example)  1 2 3, 4 4 5, this on it's own makes little sense becuase 4-4-5 is an invalid triangle is it not? I just need some sort of insight on how i would be able to order those 'raw' indices i get from the dbl. I don't care about "optimizing" or "simplifying" the model at all at this point

[dblF]

I did write a simple obj renderer that would render the model from an obj thru triangle strips so I don't bother converting for now , its still broken, in a different way though

[shak-otay]

1 hour ago, dblF said:

 the indices within the DBL are as follows (example)  1 2 3, 4 4 5, this on it's own makes little sense becuase 4-4-5 is an invalid triangle is it not? 

Yeah - that's why there's a check usually like

if ((F1==F2)|| (F1==F3)|| (F2==F3)) skip_that_face;

(Or, looks like only the actual read face index is skipped, then. Need to check the snippet more carefully. Some day.)

Edited 4 hours ago by shak-otay