.obj -> .sur converter
-
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. - v1–-> 45056 bytes
-
This might be related to the not identical tree my program generates. It would be helpful if you try to find vanilla .sur files which have a similar geometry and look how they solved it. If they used some tricks it is a bug of Freelancer. You should post it so that Skotty can add it in his tutorial then.
If not I can use your geometry for further testing, but it will take some time until I can have a look at it.
-
@ 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
-
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.
-
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.
-
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. :STo 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.
-
Yeah, that’s fine. I guess Skotty can have a look at it quite soon, for me I can’t promise, since I am (as always) quite short on time.
Maybe you could describe how you measure (or see?) the lag and also give us a short list of the simplest models to make testing easier.
-
The lag is rather obvious. The whole game locks up for many seconds, freezing the whole screen entirely. The lag appears to be purely clientside.
I’ve had a freeze upwards of 20 seconds before it unfroze.
-
That one above was solved a while ago ^^
I have uploaded a new version (see first post):
v. 1.1 BETA 1.1:
- Fixed bug which lead to missing triangle groups
- Added basic mass conversion support for non multipart meshes
- Changed automatic center calculation for target crosshair from mean to median value
- Fixed group list not updating when started via “open with” command
I must say you guys must all have used the best way of creating surs, otherwise at least one would have noticed the bug? I’ve gotten as many as one triangle out of a converted mesh I created with just a poly reducer. The other around 2000 just got “lost” Just a simple fix, though (used wrong array).
I’ve also added a simple mass conversion option for non multipart meshes. For those a special config file for each source is needed to be implemented.
Using the median instead of the mean value for the target crosshair is much more robust against outliers. The automatic calculation should now yield much better results.
If you find any bugs, please post them.
-
Nice work Schmacks, but, something wrong with the “group belongs to” dropdown menu. Clicking on it doesnt create a dropdown menu of static or moveable parts anymore - just a thicker black line - I had to manually type the _lod1 parts in.
-
I had a similar problem - for a while just two out of 10 groups appeared and I had little scroll buttons at the side of the drop down menu.
But somehow after opening 2 more times it disappeared and the full menu showed up.Since then I wasn’t able to reproduce the error again.
-
Could be a Lazarus related issue. I compiled it with the newest version (1.0.8). But neither Skotty nor me can reproduce this bug. Which Windows version do you have?
-
odd. XP with SP3 on my design compu. as you can see in the picture, instead of being populated by all the spike0x_lod’s the box is blank. No biggy as I can still type in the value.
-
I have tested it in a VM and could try what XP didn’t like with the new Lazarus version. I also made the selection more convenient.
v. 1.1 BETA 1.2:
- Fixed listbox for group selection not behaving correctly on Windows XP
- Made width of listbox more convenient for selection
As always you find the new version in the first post.
-
thats better have one on me :pint: