Custom Ships and wireframes

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.

Ok this is completly my fault, god knows what was going on but for some reason it was all to do with the test model.

Even though the vert count was massively reduced the poly count remained the same. And obviously the verts where being generated on a per poly basis, doh thank god cause it was starting to piss me off if i’m honest.

For a moment I was disappointed I not have it!
Using P1p3r’s CMP Exporter and exporting a LOD (with wireframe) got 1st result.

• If 3 ds Max exporter makes better, can it be implemented in MilkShape exporter, too?
• And with this new exporters, is the magic 18 group limit now broken?

Looks good, no?

But maybe you can reduce the polycount more for this lod?

Not perfect, but at least works, yea. It spits wire as u see a wired model in MS.
Still I cant reproduce 3ds Max version to compare them.
I think it should look like this (right pic)!

And 18 group limit is history now?

[EDIT]* Made wire_lod and exported it for best result i can have.