.obj -> .sur converter
-
@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.
-
I love that sur tool you made LS, for me it’s awesome seeing as I don’t have a community to worry about. I’ve been playing my single player mod for months now and never had a crash related to any sur your tool made, and every ship is using an sur made by your tool. I think I’m getting away with it because I don’t have any cm or mine launchers outside of the sur and they’re all single mesh models. Thanks man!
One day when I’m not feeling too lazy I might give this one a try lol.
-
Actually just was just posting an idea that could have solved one of the problems the sur builder had which was not building reduced meshes for parts of the model. Mesh reduction is entirely possible for any model using the inside/outside polygon check. I just meant that I should have made the vertices spacing check auto-adjust according to the bounding box or bounding radius of the model instead of using a single user specified value.
No offense to your tool, you actually got it working were as I did not. I may work on it again to finally complete the tool as it should have been in the first place to output files for my game. I doubt I will finish it for FL since I don’t understand the bits section (the BSP tree stuff) and I don’t see any reason to compete with your tool nor would I want too.
-
Lazy people like me really wish you would LS!
I can’t get to grips with this tool of yours Schmack.
Converting the cmp for my average fighter to an .obj then using directx tools to reduce the model as far as it can go without falling apart still leaves me with an sur of over 200kb, which i guess is bad news. Looking at vanilla sur’s that’s way more than a fighter should have.How many kb is too big for FL to handle? Can I get away with these 200kb files or is it a case of having to make new models to make the sur file from, cos I can’t be arsed to do that, way too lazy and too little time lol.
If only there was some tool that would give me a simple outline of the fighter mesh!
-
If you check “Only use the outer convex hull as collision mesh” my tool does the same as the tool from LS (but a lot faster).
200kb should be ok for today’s machines. Also the ones generated with the new version should be smaller. If you don’t have big ships you don’t need that much detail so I only would recommend not to use the outer convex hull for bigger ships.
I experimented with meshlab and got some nice results with polygon reduction for bigger ships, but it is not that easy to use.
Since there is no tool out there for other games which automatically builds a collision mesh I doubt you will get around building them yourself or accept the bigger file size. Or just use the outer convex hull.
@LS: I will try out some techniques for building better collision meshes if I have the time. I think the most importing this is, that we now can use the .sur format in all its complexity. That’s why i focused on that.
-
Schmackbolzen wrote:
If you check “Only use the outer convex hull as collision mesh” my tool does the same as the tool from LS (but a lot faster).200kb should be ok for today’s machines. Also the ones generated with the new version should be smaller. If you don’t have big ships you don’t need that much detail so I only would recommend not to use the outer convex hull for bigger ships.
Well it’s all good then, nice one man!
-
Since there is no tool out there for other games which automatically builds a collision mesh I doubt you will get around building them yourself or accept the bigger file size. Or just use the outer convex hull.
Well there is somthing you can use out there. There is the Havok Content tooll for 3ds max that can specifically make collision meshes by wraping the meshes in your scene.
For 3ds again there is also the PhysX plugin, this does the same thing.
One is better than the other at making working meshes. And one is better because it will wrap the groups in your scene automatically. But the other one would wrap a 1 mesh round the whole model and the only way to get round this is by selecting each group individually and do it over and over.
Both tools work great though, it’s what i use for making any hitbox for FL.
all you have to do is export the final product as a obj and run it through the converter.
Or maybe i am just misunderstanding the question?
-
Schmack, yes would you please explain what this setting does “Only use the outer convex hull as collision mesh”?
I’m not clear on it yet either. Thanks
-
I think it does the following (based on the comment that it’s good for small objects):
If you have a small asteroid and you use automatic hull generation of it (just by not creating a convex hull by hand), only the outer, convex hull that every sur file has (normally used for detection of the sur) is used for the collision.
Means: Autosplice creates a lot of single sur meshes. The convex hull around it just “overwrites” these single sur meshes. Means you just have 1 convex mesh, wrapping the whole model.
