.obj -> .sur converter

Well I tested it out. The main part that doesn’t move, works 100%. The rotating part, doesn’t. Don’t get me wrong here I appreicate the effort. I see what you mean with the convex tool. But I thought surs had to have under a certain amount of parts. Or am I wrong on that?

SURs can have as many parts as you wish. But always keep in mind: the more parts/polygons, the more the computer has to calculate. In Freelancers case, the physics are rather simple and you always have to see the object in its real size. If it is really big, for example this jumpgate, don’t hesitate to use a lot of groups. If it is a little object, nobody will ever notice the inaccuracity.

I just tested around with the object because just before you wrote I was talking with Schmackbolzen about the program again.

I found out: we never tested what happens if you want to create moveable groups with more than 1 mesh. In your case, I put them together with “Belongs to”. As you see, it doesn’t work right. The better/correct way would be to give all meshes of the same group the same name (as you do with static sur meshes).
And here is the current problem: Because we never tested this we never noticed the bug the converter has. So, for now, moveable groups are just working if they are single meshes or, maybe, if they are sticked together with Belongs To.

A little workaround for you:
Make all the ring objects static, too. Because it just rotates, the player won’t notice the moving parts that much as he does on normal jumpgates.

(In general, always keep in mind what the player will notice and what not, so you can simplify surs as much as possible.)

I tried to use MilkShape ConVex Tool:
1. Load prepared .ms3d, Ctrl+A, ConVex Tool, Del, Export to .obj.
2. Convert .obj to .sur, without checking second checkbox.
It’s easy and worked fine with “newgate” sur (big tube), but it does not work with this sur:

@Jolly_Roger:

Did you use “smoothing groups” –> select 1/assign after deleting the non-convex ie: original sur parts?

No.
I tried, no effect for this sur.

When you say it doesn’t work with this sur, what does that mean:
You don’t get convex surs, got error message in ms, ctd in game or what?
What version of convex tool do you use?

Many collisions not detected, especially from the inside.
It happens that the sur does not detect any collisions for several seconds at a time (sur may be “offline”?).
msConVexTool.dll has not contain information about the version, file size is 110 592 bytes. I not found another versions.

Updated:
Another version ConVexTool from page 22 of this topic, same result.

Just a general note:
If someone has problems with converting surs, it would be extremely helpful to have a picture of what you did in the Obj - Sur Converter!

When using the Convex Tool you dont need to smooth any group. Just delete all “original” meshes and export it.

The meshes of your sur are absolutely correct.
I also have the same problem you have with this sur. This seems to be a bug in the program. At least, it always happens again. I merged a few meshes together, so changed the structure a bit, but it’s still not working.
So this is something I cannot help with. You just could try to rebuild the meshes or change their positons etc. Maybe reposition the whole model.

@Jolly_Roger:

msConVexTool.dll…size is 110 592 bytes

That’s too big imho. I’ve got 2 different convex tool:

• v1–-> 45056 bytes
  -v1.1 —> 53248 bytes

I don’t know what kind of convex tool you use but I suggest to try the versions posted above I belive they can be found at the download section.
Anyway, Skotty is right, sometimes this error caused by the program itself and there is no solid way to fix it. You might try excluding each surs from the first to the last and find that one which is responsible for the trouble. It’s gonna take several hours though.
But it’s really weird, I had same problem when I used ms.sur exporter. Since I started to use otsc I haven’t had this issue.

@ Davis: You don’t need to discuss about the “right” Convex Tool. Version 1 and Version 1.1 and the one I uploaded on Page 22 (Version 1.1 with _lod1 ending except _convex) are ALL working as they should!

As Schmackbolzen said, I am always open to help people with their Sur-Problems since I experimented a lot and know how to use Schmackbolzens program the optimal way. Also how to make them fit with P1p3rs CMP exporter is my speciality if you use multiple groups with Fix/Rev/Pris entries.

Does ANYONE has interest in more tutorials?:

• how to create optimal physical models of your object
• how to use the Sur Converter for simple objects
• how to use the Sur Converter for fighters
• how to use the Sur Converter for battleships
• how to use the Sur Converter for stations

@Skotty:
I meant no offense bud. I just said v1 and v1.1 work fine with otsc and they might worth a try.

Davis: Skotty didn’t take offence, by “you don’t need to discuss” he means “you don;t need to worry about” - he’s not a Brit or Yank, so make allowances for language, most people here are bilingual and English is their second language. How well do you write in German?

The two versions of Convex Tool are similar but one opens a dialogue box asking for a value before executing the convex process. That value is a distance that it will lift the sur away from the model surface. As it should be 0, I don’t use that version so that I don’t have to press an additional key.

The other version of ConvexTool that Skotty mentions is just fixed to rename the convex parts to partname_lod1 ready for sur generation - the original tool renames the convex parts to pertname_convex so it is necessary to rename each part to partname_lod1 manually - this would need another step. We like shortcuts.

Remember, despite Skotty’s no experience of problems using the Convex Tool, I have had some. So just be aware of the possibility of a convex part not being totally convex if you have problems with your sur.

And in ship surs, certainly you can omit all sur hardpoints - just be prepared for intermittent crashes that you can’t account for. I tested my surs over several hours and crashes were happening after from between 5 minutes and sometimes over an hour of heavy intensive NPC vs NPC combat testing. In game I was getting random crashes maybe days apart, or sometimes as soon as a player entered the system the sur was used in.

If you test your sur by flying round a single ship fitted with it, and blasting and bumping it, you won’t see these problems. But when you give your sur to one NPC faction and blast them continuously using enemy NPCs, you will see a different story. If you clean up your surs in this way (add the minimum necessary hardpoint surs) and test by this NPC combat method overnight without failure, then you have bulletproof surs and that is surely a good thing. Many mods are plagued by intermittent crashes. This is one cause of those, and we know it can be easily removed.

As my good pal BejayMac often used to say, I’ve taken the horse to the water, and now it’s up to the horse to drink, I can’t force it to drink.

I tried shift, resize, and rotate sur, this not fix a problem.
Small experiment, the problem seems in parallel parts.

Updated:
I make sur from two parallel parts of this sample (without central part), not all collisions detected.

Might be more useful to post the OBJ files which you are generating the SURs from Jolly… And add the CMP as well, if you’re doing a multipart SUR, the names must match up with the groupnames in the CMP, with a _lod1 suffix added. That’s a common oops for not getting a collision detection going.

So, I have this weird collision bug again with our .surs. It’s been around for a bit, more pronounced since the latest iteration of the obj–->sur converter, since I redid all the FW:ToW. Basically, before, I was just loading HpMount on my surs, just to get the wireframes working - before, for whatever reason, it used to be needed.

That said, I noticed that we only get the collision lag when two flying objects meet. There is no lag when one hits a solar. So, I did a little test. First with no hardppoints at all in the sur creation on all the ships within the scene. The next with all the ship hardpoints in the sur creation on all the ships.

Funnily enough, I get lag with both instances. It’s definitely more pronounced on the ships that have more hardpoints in the sur.

That said, any idea what could be going on? Most of my hitboxes, except for capital ships, are under 1500 polygons. So, I don’t think it’s complexity.

Any thoughts on what I should try? I guess I’ll try a run down of Skotty’s tutorial to see if there is any improvement overall.

Schmackbolzen wrote:
This is very little info to make any conclusions. Are all the groups static? Who is colliding (player or npc)? What are the simplest models where it occurs? Are there models which don’t have that problem? You should experiment with the simplest model where the problem occurs. If you can’t solve it, give us the .obj and .sur and .cmp so we can have a look at it. After all it might still be a bug in the converter. If you solve it please post what the problem was so Skotty can add it to the tutorials.

To answer your question in order:

1. Yes, all the groups are static.
2. Player to NPC. Player to player also have this problem. NPC to NPC doesn’t seem to lock up the client
3. No, all models have this problem.
4. Already done. Had the same problem. :S

To take a look at the problem, I might have you give both you and Skotty access to the FW:TOW SVN, if that’s OK? I didn’t think about testing the ship in vanilla FL, although I don’t think it’s anything we did to the freelancer.exe.

I’ll add you both to our project on the SVN now and send you links.