.obj -> .sur converter
-
StarTrader wrote:
P1p3r seems to have disappeared?
Yes, sadly he did. His exporters and importers are great, but have a few incorrect things that would make it much easier to work with the sur converter.
-
Thanks for your converter Schmack.
And thank you for your tutes, Skotty, great work.So are those the latest importer and exporter?
-
Here they are, P1p3r’s latest importer and exporter, to save people time. They are the same ones as I uploaded on the original thread, but it takes time to find them there.
Does the importer (or exporter) still reverse the harpdoint triangles or was that fixed?
Has anyone heard from P1p3r? It’s worrying, in case something happened to him?
-
“Automatic” center calculation worked incorrectly, but for “Static” parts and “crosshair”.
I select part in Milkshape and look center of selection in model statistics.
After export to .cmp by P1p3rs plugins, i check coordinates of part in “Fix data” section by UTF-editor, and see same (correctly) coordinates.
I check .sur file by surdump, and see another (incorrectly) coordinates of part.
This made AIM and damage issues, for large (100+ meters) multiparted ships and solars.
If i input manually negative parts coordinates, and set 0, 0, 0 for crosshair, all worked fine. -
Revised bugs information.
1. “Automatic” coordinates calculated correctly for single chunk “Static” and “Moveable” parts, and incorrectly for multichunk “Static” and “Moveable” parts.
2. Different coordinates required for chained parts. First .sur part, used as part of ship, should have coordinates, relative of a parental group. Secondary .sur part, used as debris, should have absolute coordinates (concerning the centre of model).
3. If parts are located in one or two planes, all works correctly. If parts are located in three planes, it is possible to fly by through sur. Is that problem, which I described earlier. One more example of incorrectly worked sur, you can fly out of dock through a wall.In addition, I ask about adding ini-files support, with settings for sur chunks, it would be very convenient.
Possible, the author publish source code of the converter, for independent modifications by the interested persons? -
Have you tried to follow this series of tutorials?
http://the-starport.net/freelancer/forum/viewtopic.php?post_id=54168#forumpost54168 -
Yes.
This two little and very simple examples:
surtest.cmp/sur, contain four cubes, located in two planes, and worked fine.
surtest2.cmp/sur, contain eight cubes, located in three planes, and worked bagged, sometimes you can walk through cubes.
What here wrong? -
I don’t know whether you are familiar with tree generation in computer science, but I tricked a little bit when I wrote the code for generating the BSP-tree. It’s more like a KD-tree and I suppose that’s why it does not always work. Either that or it is the freelancer collision itself. I plan to change it to a real BSP-tree, but atm I absolutely don’t have the time for it. Maybe in a month…
That said, making it open source would not help much I guess. The code in a whole is quite complicated and I am not happy how things are structured, since I had to test lots of stuff. Getting it clean for everyone would take a lot of time and I am not convinced that it is worth it. It is written in freepascal anyway, so I doubt there are a lot of people who know how to change stuff.
Concerning points 1 and 2: I am not sure where you’re getting at. Most of the stuff should be covered in Skotty’s tutorials. Could you try to explain what is not covered there with a more elaborate example?
-
All your files are fine. Theoretically there shouldn’t be a problem. I guess either it’s a converter or Freelancer problem as Schmackbolzen said.
-
I yet not completely have understand problems of the centres, while I can show one example.
I see strange automatic calculation of the centre for crosshair, it not the centre of mass, not the centre of symmetry, and not the centre of coordinates.
Possible, this place of crossing of parts, or so has coincided. -
In one of the last versions I changed it to use the median of all points instead of the arithmetic average. Since most of the points are on the upper y-axis you get that result. The idea was to filter out outliers. If you have a better idea how to calculate it be my guest
-
I have a problem with the automatic center calculation.
Missiles / torpedoes / mines, guided by converter calculated center, and if it is too far from the geometric center of model / part, the explosion does not cause damage to ship, due to the fact that the geometric center misses the explossion radius of the munition.
I would not want to increase explosion radius, as it would be too damaging smaller ships, and I have to manually enter the coordinates of the centers. -
That’s why you can set a manual center in his converter. You are right there and that is intended.
You can’t solve this automatic center calculation for all cases. If you have a ring, the center of mass will be inside the ring, and there is no geometry at all. -
It seemed to me that the median is used as well for the calculation of the center of each part?
Because of this, I point out manually center for all parts that would avoid the problem of explosion and problems with moving parts.
It would be very convenient to have ini-files, describing the properties of parts for the converter (type, coordinates, parental part), for easy modifying .sur later. -
Please tell me, how to properly search “Opposite” triangle in convex hull mesh?
Now i’m looking for the intersection from barycenter, in the direction of the inverted normal, and it seems to work.
I have found differences in the choice of opposite triangle, in different exporters.
1. Vanilla exporter, work approximately as my, but sometimes it hits in the neighboring triangle.
2. msSURExporter v1.2 seems looks for a triangle, with the maximally oppositely normal, without position check.
3. May be i’m most to draw a line, from the barycenter, through the center of the mesh, and find the intersection with this, i‘m doubt it. -
From memory I use the most away faced normal I can find. I can look it up if you need it. Which brings me to my next question: Why do you want to know this?
-
I’m writing a command line converter in C++, which using more model fixes, and .ini files for best usability.
Now supports - import from .cmp/.3db/.mat/.ms3d, export to .cmp/.3db/.mat.
Also, i’m need for fully correct .sur files, i’m working now for this.
I would like a good understanding, for what is needed and how they must be made the opposite triangles, for create correct code. -
Jolly_Roger wrote:
I’m writing a command line converter in C++, which using more model fixes, and .ini files for best usability.
Now supports - import from .cmp/.3db/.mat/.ms3d, export to .cmp/.3db/.mat.
Also, i’m need for fully correct .sur files, i’m working now for this.
I would like a good understanding, for what is needed and how they must be made the opposite triangles, for create correct code.It’s better than ms3d-s cmp exporters ?
-
Perhaps one day the FL community will get out of the stone age and stop using the trash heap that is MS3D. I mean, there’s already a 3ds Max exporter that works much better.
