.obj -> .sur converter
-
@Goulash:
Actually there should be no models which don’t work (except for too much vertices). If you are absolutely sure it’s not a problem with the .cmp file (wrong group names etc) then could you please send me the .obj and .cmp file and your settings so that I can test it myself.@All:
Skotty has said he his willing to write sort of a how to text, but this will take some time.Also don’t hesitate to post your feedback. It has taken a lot of time to finish the tool and of course I want to know how it is working for you.
Also if I forgot to explain something just ask, it is difficult to think about all the questions one might have.
-
Very many thanks, Schmackbolzen, your long effort is very much appreciated as always.
And thanks to you too, Skotty, for your testing, I know how long it takes.
Just a quick query: are the default settings good for most vanilla ships?
Or what settings are better?
Thanks again.
-
You can leave the default settings. They work good for nearly every sur (I never had one of my surs where I needed to change these settings).
Just make sure to create convex meshes, I recommend the Convex-Plugin for Milkshape for this. -
Skotty. wrote:
You can leave the default settings. They work good for nearly every sur (I never had one of my surs where I needed to change these settings).
Just make sure to create convex meshes, I recommend the Convex-Plugin for Milkshape for this.I have the plugin Skotty, but am I suppose to use it if you don’t mind me asking.
-
Schmack, got a question.
I’ve used your older version of the exporter for all the models, 200+ in the FW:ToW mod. We’ve tested every hitbox the best we can and from we can tell, everything is working. It’s a fabulous tool.
That being said, would you recommend I reconvert all the .objs again using this version of the exporter or should I just leave it as is Is there any advantages in reconverting them with this version?
It’s only about 2 1/2 hrs of work as I have all the .objs saved.
-
Yes, I recommend it. The recognition of convex shapes now is much better plus there was an error which lead to garbage at one offset. FL doesn’t seem to use it but you never know. Also because of the better recognition the files should be smaller, which also means faster. It would be interesting if you could post numbers of the file size difference. That should give an indication of how often the old recognition was wrong. Also in some cases the triangles of a particular group got mixed up which might not always have been noticed by you.
-
Schmackbolzen wrote:
Yes, I recommend it. The recognition of convex shapes now is much better plus there was an error which lead to garbage at one offset. FL doesn’t seem to use it but you never know. Also because of the better recognition the files should be smaller, which also means faster. It would be interesting if you could post numbers of the file size difference. That should give an indication of how often the old recognition was wrong. Also in some cases the triangles of a particular group got mixed up which might not always have been noticed by you.OK. Thanks Schmack!
-
@Ezekiel: Thanks!
@Sushi: I just was thinking. Since you were experimenting with the hardpoint stuff, you could test to include the geometry for all your hardpoints on a complex model. Then you could make assumptions about how much performance improvement this gets. Since you noticed quite a boost through the bsp tree this also should be noticeable.
I am trying to read .cmp files as a next step, so if your release is not in the near future you also could wait with converting all of them again and automatically let the tool include the hardpoint geometry.
-
Schmackbolzen wrote:
I am trying to read .cmp files as a next step, so if your release is not in the near future you also could wait with converting all of them again and automatically let the tool include the hardpoint geometry.What are you saying here exactly? Convert straight from .cmp to sur?
-
It won’t use the geometry of the CMP, but it will add all hardpoints to their sur parts and it will also make all sur groups belong to each other like it’s set in the FIX file.
-
Congrats Schmackbolzen, glad you made this! Never figured out the bits section but it seems you have. I spent several months as well working on this problem so I know how hard it was to build this tool, you made it farther than I did.
A simple request, could you make it where it outputs a file other than a sur file such as obj or fbx? Some of the test models in GE have a massive poly count (> 500k) and would benefit from a low poly collision mesh.
-
The converter itself wont create a low poly mesh. Thats the work of the 3d artist. It will just generate a automatic sur out of each polygon of your obj file if it’s not concave.
Creating physmodels per hand is a important job, because on that way you can be sure to use a low poly count without ignoring maybe important parts of the ship.
-
Schmack, I was speaking with Sushi minutes ago and I wondered… Did you end up adding command line support? Even something primitive (convert given OBJ to SUR with default settings) would be more than enough, could then make a small batch file to pass through all the OBJs we have.
It’d tremendously speed up the reconversion process
-
I was thinking about it, but I had to draw the line somewhere. There are still a few things left I want to include, but this would have delayed the release even further. So I decided to release after every feature of the .sur format was supported and I had fixed all bugs I found during development.
I am still not sure whether it wouldn’t be better to include mass conversion support directly into the tool. Then again if someone wants to write a complicated batch conversion script it might be better if the tool works on command line level. Maybe include both features? I don’t know yet.
@LS: Thanks! But I have to agree with Skotty here. The more polygon count you get the better it is to let the 3d artist do the work and let him build a low poly collision model out of convex bodies. I had the idea about an algorithm which does that for you but I wont have the time anytime soon to test it.
@Timmy51m: It makes no sense to read the geometry out of the .cmp file since the collision mesh should not be the same as the 3d model.
-
Integrated mass convert works too really and would perhaps be more accessible; I was just looking for the simplest solution on your end. If you want to do a full UI for it, go for it!
In any case, I perfectly understand your point and thank you for releasing this at all. I was merely asking since it wasn’t mentioned since I pointed it out the first time around.
-
Well I am willing to give you access to my code if you want code for auto-reducing polygon count. It’s mainly built upon point distances, point clouds and max point spacing. I may just work on the sur converter again and rework it to output simple meshes in .X format. Kinda wished I had made it automatically adjust the spacing by the bounding radius of the specific sub-part of the cmp, probably would have fixed the missing model pieces problem.
Anyways, thanks for answering. -
I was thinking about that problem for some time and came to the conclusion to let the modeling software do the job. There is just no algorithm out there which works perfectly for every model. In fact most of them work for just one model and after that you have to adapt the settings. There also are a lot of meshes which are very bad for polygon reduction. Another point was, that the splicing is just a less-than-ideal solution, since it increases the computing power needed for the collisions by magnitudes.
If you look at other games they all use an extra collision mesh build out of convex bodies. And for that I was not able to find any algorithm so I suppose they are build by hand. -
When I used the Mesh reduction in MilkShape it’s not been very successful and warps the shape too badly to reduce the polycount significantly.
I’ve always created convex parts in the modeller (MilkShape’s Convex Hull tool or 3DS Max’s Havok tools) and then run those through the sur process.