Custom Ships and wireframes

And just to add on this body of knowledge

Each equipment wireframe that you attach to the model counts to this overall amount.

Meaning that if you have a model that’s just under 16000 and you add a number of equipment pieces, the wireframe will not work.

So like:
ship model = 15000
equipment = 2000
Total count = 17000

Wireframe will not work.

Am I out of luck?

It seems so.
To be sure, just place the ship as a solar object into space or give it some NPCs and select them to see the wireframe… or not.

Ugh. It seems that I must once again reiterate why I dislike Dev’s wireframe creator.

While Dev’s program does create a wireframe correctly, it’s ugly and far larger than it needs to be. It’s far better to build them by hand; while tedious and time consuming, it produces a cleaner wireframe that uses far fewer vertices. If you want to see the difference, compare the first and second pictures here.

Normally a good baseline is to use your SUR’s model as a wireframe. Using the actual model is asking for a jumbled mess of lines.

The wireframes in those pictures in the other thread did use the SUR model. That’s the sad part.

Then there are far more concerning problems than wireframes to address…

meshes are triangulated while wireframes are lines, that is a significant difference which makes using one type for the other complicated. at one point i thought about making a wireframe tool that would let you build the wireframe lines by clicking on the vertices connecting them in a kind of 3d editor.

I believe (not 100% sure) that if you use w0d’s exporter the wireframes use the actual polygons (of arbitrary number of edges) defined in 3ds Max as opposed to the triangulation of said polygons.

FriendlyFire wrote:
Then there are far more concerning problems than wireframes to address…

If you’re implying that the SUR model was too complicated, it was 352 triangles and 212 vertices, and it still produced that mess.

That’s why I dislike Dev’s utility; it uses all the vertices in the model used and draws lines between all adjacent vertices, causing a mess of lines, instead of just doing an outline of the ship. Furthermore, if you use a simpler model for the wireframe, you have to load load that model into the CMP in addition to the model which is viable, which drives up the file sizes and is really aesthetically unpleasing IMO.

TBH, I can’t think of a way to build a nice wireframe except by hand, unless someone designs a program where you can load the meshes, connect the vertices you want to be in the wireframe, and export it as VWireData.

FriendlyFire wrote:
I believe (not 100% sure) that if you use w0d’s exporter the wireframes use the actual polygons (of arbitrary number of edges) defined in 3ds Max as opposed to the triangulation of said polygons.

So then don’t use Dev’s util, use W0d’s. It’s what we use for FW:ToW, and it produces fantastic Wireframes for even my high-poly clusterfucks.

That’s Sizer.

[RIP]Fusion wrote:

So then don’t use Dev’s util, use W0d’s. It’s what we use for FW:ToW, and it produces fantastic Wireframes for even my high-poly clusterfucks.

Sushi, could you link this program of W0d’s?

Fus

http://the-starport.net/freelancer/forum/viewtopic.php?post_id=49778#forumpost49778

May I ask does the Pip3r’s MS-CMP exporter produces same wireframe?

Unsure, I haven’t been able to get it to work. Not only that, the new exporter allows proper smoothing of models. This is critical for proper normal/specular mapping process.

Anywho, this is a link to the 3ds Max CMP Exporter: http://forge.the-starport.net/projects/maxcmpexport

Here’s a brief overview of how to use the exporter:
http://www.youtube.com/watch?v=hSd2jJnND1g

There is a problem with the LOD groups with the exporter right now, i noticed this about a week ago and have been trying to fix it since then with no luck at all.

Just by looking at the video again you should notice it yourself, there should be a new VMeshData for every LOD.

Each VMeshData should have less verts than the first, instead the exporter is writing the new LOD to the same VMeshData. Doubling the Meshes in it and also the verts.

Now I imagine this would be fine if it was actually writing the meshes with the lower poly and vert count to the VMeshData. But it isn’t, it’s duplicating the first LOD.

I thought at first it had somthing to do with the mesh splitting that i had added myself to the exporter or the rotation animation export. But i’ve reverted back to the original re-written version and it is the same deal.

Odd. I can easily view all the LODs in UTFEditor and it isn’t showing the first LOD at all. In game, there’s also a noticeable difference in the LODs and it shows all of the LODs I specify. Furthermore, with FW:ToW debugger, there’s a decrease in the amount of polygons displaying on screen as I get further from the object.

Unless, I’m interpreting what you’re saying wrong?

SilentAssassin82 wrote:
There is a problem with the LOD groups with the exporter right now, i noticed this about a week ago and have been trying to fix it since then with no luck at all.

Just by looking at the video again you should notice it yourself, there should be a new VMeshData for every LOD.

Each VMeshData should have less verts than the first, instead the exporter is writing the new LOD to the same VMeshData. Doubling the Meshes in it and also the verts.

I know that most of the FL models are done in this way, every LOD having its own VMeshData (hence the _lod0 and lod1 etc…). However, the exporter does not do it in this way, meaning that all the different lods are in one VMeshData. As Sushi said, FL allows for that since the VMeshRef is the important thing to care about, as it actually identifies the meshes within the VMeshData.

If the VMeshData gets too big (i.e. over 65536 indices or something like that), it automatically gets split and another VMeshData is created.

Now, what this design does not allow for is different vertex formats for different lods (I think some FL models have that) but yeah, I left that out for simplicity.

Yeah, i know it could work with all the LODs in the same VMeshData. But that’s what i meen, it’s not writing the lower poly mesh into the VMeshData, it’s duplicating the first LOD, you can tell just by the fact that the vert count for each mesh remains the same.

Do you have an example file because it doesnt do that with the models we have.