Getting model into game

[anomaly]

I've been having trouble getting this model I made to work in the game.  I originally made this in Cinema 4D, exported to .x format and (since x2xsi doesn't work for me) I copied the coordinates and stuff into an .xsi file.  The layout of the xsi in notepad looks correct compared to all the other xsi's I've seen, and I can even get the model to open in Threed but, when ever I use it in the game, bz2 crashes. 

Here's the error:

Code Select Expand

[ E X C E P T I O N ]
Patch 1.3pb3 EDITOR Aug 10 2006 08:26:12
Type:    ERROR
SubType: FATAL - fatal error
Message: Too many vertices in a tri in: smship00.xsi
Module:  .\meshread.cpp
Line#:   458
Stamp:   Sun Mar 19 23:18:25 2006
CallStack:
7C812A5B +7C812A5B kernel32.dll [Unknown] [Unknown] [Unknown]
0054485A +00B2 bz2edit.exe system debug.obj void __cdecl Debug::Error::Err(char const *,...)
00568E87 +006E bz2edit.exe EXE  void __fastcall ReadFaces(class std::istrstream *,struct MeshFeature &,bool)
00569306 +012A bz2edit.exe EXE  void __fastcall ReadSINormals(class std::istrstream *,struct VectFeature &)
00569884 +0169 bz2edit.exe EXE  bool __fastcall ReadMesh(class std::istrstream *,enum XFileToken &,class Mesh &)
0056A95F +00FA bz2edit.exe EXE  bool __fastcall ReadMeshGroup(class std::istrstream *,enum XFileToken &,class Mesh &,class AnimKey *)
0056BE2B +0451 bz2edit.exe graphics meshread.obj public: static class MeshRoot * __fastcall Mesh::Manager::FindRead(char const *)
0056B9B5 +0059 bz2edit.exe graphics meshread.obj public: static class MeshRoot * __fastcall Mesh::Manager::FindRead(char const *,float,bool,bool,bool)
00496849 +0213 bz2edit.exe EXE GameObjectClass.obj public: __thiscall GameObjectClass::GameObjectClass(class GameObjectClass *,char *)
0047C68B +0019 bz2edit.exe EXE BuildingClass.obj public: __thiscall BuildingClass::BuildingClass(class BuildingClass *,char *)
0047CA73 +001C bz2edit.exe EXE BuildingClass.obj public: virtual class GameObjectClass * __thiscall BuildingClass::BuildClass(char *)
00462257 +0094 bz2edit.exe EXE EditObject.obj public: static void __fastcall EditObject::Command::Process(unsigned long)
005470EA +0018 bz2edit.exe utilsys varitem.obj public: void __thiscall VarSys::VarItem::TriggerCallBack(void)
0057AFB7 +0122 bz2edit.exe EXE  bool __fastcall IFace::InputEventHandler(struct Event &)
0046E88B +0036 bz2edit.exe EXE MissionHandler.obj public: static void __fastcall MissionHandler::State::EditState::Process(void)
005501B0 +0130 bz2edit.exe main runcodes.obj public: void __thiscall RunCodes::Process(void)
0046C305 +000B bz2edit.exe EXE MissionHandler.obj public: static void __fastcall MissionHandler::Process(void)
0054FCB8 +004B bz2edit.exe main mainproc.obj public: static void __fastcall Main::MessagePump(void)
00458549 +0061 bz2edit.exe EXE  void __cdecl AppStart(struct HINSTANCE__ *)
005D39D7 +0177 bz2edit.exe LIBCMT wincrt0.obj ___tmainCRTStartup
7C816FD7 +7C816FD7 kernel32.dll [Unknown] [Unknown] [Unknown]
Registers:
EAX: 02049510h   CS: 0000001Bh  DS: 00000023h
EBX: 00000000h  EIP: 7C812A5Bh  ES: 00000023h
ECX: 00000000h   SS: 00000023h  FS: 0000003Bh
EDX: 01D2F922h  EBP: 02049560h  GS: 00000000h
ESI: 02049590h  ESP: 0204950Ch           
EDI: 0B0FB808h                       
CF: 00200206h PF:0 AF:1 ZF:0 SF:0 OF:0
Entering critical shutdown

At the top it says something about too many verts in tris.  I assume that means its getting hung up on 4 or 5 point polygons but, my model doesn't have any!  I made sure to convert all polygons to triangles before exporting.

Does anyone know a solution or if this error is also a sign of something else?

Oh, and in the .xsi file, do the numbers of spaces between the left margin and the coordinates matter, or are those only there to make it easier to see the different sections?

[General BlackDragon]

how did u make the model? whats the poly count?

[bigbadbogie]

that happens when the ship has too many vertices - i usually get it around 900 - 1000 verts - try to keep models under 900 verts

[Spawn]

I have also heard of this problem occurring if you have vertices very close together, but most modeling programs have a feature called "weld" that can fix the problem.  At least its called weld in 3dsmax.

[anomaly]

Vert and poly counts are pretty low, so that shouldn't be the problem.
Vertices:162
Polygons:316

I have also heard of this problem occurring if you have vertices very close together, but most modeling programs have a feature called "weld" that can fix the problem.  At least its called weld in 3dsmax.

I might have left a copied vertex on top of its original. I'll look into that.

[bigbadbogie]

very curious - i guess this is what happens when you use different modelling programs

maybe try exporting it to 3ds (or any format that your program recognises) and re-import it into a new file

that sometimes fixes little problems which get ironed out during the export/import processes

[OvermindDL1]

"Too many vertices in a tri in:" is a common error, the exact reason is that in a mesh definition in the file, at the left of a face definition is the number of vertices that make it up, which must be less then two and times three less then 256, in other words:
((vertex count of any given face)-2)*3 must be less then 256
Or that above error will be thrown.  Hence, BZ2 does support multi-vertex faces, and quite a lot of them actually, but you have a number that is too big.  Most common reason, it is happening in one of the normals section of one of the mesh's in the xsi file, specifically instead of being something like "26;3;103,104,105;," it is something like "26;103,104,105;,", the left number in the normal's is the index, but the second is the count, and most do not put an index, but rather have the left most number be the vertex count with the index count not existing, where BZ2 requires it to have the index count on the left if the normals section is named "SI_MeshNormals", but can support the other method if it is instead named just "MeshNormals" or "XSIMeshNormals" (xsi 1.0 uses XSIMeshNormals where 1.1 uses SI_MeshNormals, and XSIMeshNormals is identical to MeshNormals, either can be used, but SI_MeshNormals obviously is not).  If you let me see your xsi file I could probably find the reason.  If it is because of the normal section being formatted without the index number then changing SI_MeshNormals to just XSIMeshNormals would probably work.
Generated by OvermindDL1's Signature Auto-Add Script via GreaseMonkey

[anomaly]

Gah! attack of the run on sentence!

I think you need to clarify that first part because by my understanding you're saying a polygon can have around 87 vertices before causing an error. ((256/3)+2)  How exactly can you exceed 256?

I tried just changing SI_MeshNormals to MeshNormals and still got the same error.  Are there any other section titles I should also change? Like SI_MeshTextureCoords?

Edit: Ok I just tried changing SI_MeshTextureCoords to MeshTextureCoords and it works!
A bit big but it looks fairly good in game.

[General BlackDragon]

strange....

[BNG Da BZ Fool]

So just dropping SI_ did the trick to get it to work? Very cool little tidbit of info to remember. I guess specific formating is essential for the BZII engine or any other for that matter to work properly. I remember a while back when converting some ASC files to X via 3DEX I encountered some read errors trying to open the files in BZ2ME. Anyways I finally figured out that to get it to open; I ended having to add a top-level frame to get it work. I'm still amazed by how one little missing piece of information can create total chaos for the game engine, and hair pulling frustration for the modeler.

[OvermindDL1]

Yea, the texture area is the next most common.  I know lots of little tips and tricks like that about the xsi files now.
And those are the things you have to put up with on such an ancient model format.
Generated by OvermindDL1's Signature Auto-Add Script via GreaseMonkey

[Avatar]

You have no idea how many times people have come here in total agony because their models produce that error...  this is massive...  Any such tricks should be stickied for the masses...

-Av-

[OvermindDL1]

I only learned it recently.
Generated by OvermindDL1's Signature Auto-Add Script via GreaseMonkey

[Angstromicus]

Stickied. But it looks like all these stickies on this board is causing quite the "overhead" . Doesn't look like any of the topics can be cleanly combined, though.

Edit:

It looks like Lizard's BZII mapping and Modding effect would be a nice place to put the info from the less active topics like the Gmax and mapmaking/pathing topic. But I don't want to make any moves yet because nobody's complained.

[OvermindDL1]

Perhaps having one sticky with links to all of the other useful things, but the useful things are unstickied so they can just float away?