Important Message

You are browsing the archived Lancers Reactor forums. You cannot register or login.
The content may be outdated and links may not be functional.


To get the latest in Freelancer news, mods, modding and downloads, go to
The-Starport

Complex (and working) .sur files

The general place to discuss MOD''ing Freelancer!

Dev

Post Mon Jun 12, 2006 12:57 am

Complex (and working) .sur files

I don't know how well other people have been fairing with the rather disagreeable .sur files, but I figured I ought to share my recent success story with the rest of the modding community.

Basically, what I noticed is that the bit headers section is very difficult to get a handle on. For models with multiple parts there are often many extra bit header sections that don't correspond to any actual geometry, and setting these up correctly is like shooting in the dark (at least for me). I spent many, many, many frustrated hours tring to completely figure them out, but eventually I found myself about where I'd started. That being said, any surface with just a single mesh generally has only one bit header section, which is quite manageable.

The .sur exporter that we all know and love forces you to choose either a bubble or shrinkwrapped shield. Unfortunately, this leaves you with more than one mesh in your surface, so what I did was write a simple program to strip off the shield mesh of a .sur file that came from the .sur exporter. The result: a collision surface that completely worked under all circumstances. After some more testing I discovered that to be reliable it also needed to be convex (this we already knew, but I figured I would test it anyway). Additionally, I am 95% that the arrangement of the triangles in the mesh matters; using just default boxes or other shapes in MS3D always gives me results that work, but trying to make the triangles by hand by connecting vertices tends to fail.

Also of interest was shield behavior. Prior to this I wasn't aware that Freelancer would default to using your hull hit box for shields if no shield mesh exists, but it most certainly does. Even hits against mounted equipment will count as shield hits so long as the shield is up. So, as long as you're willing to settle for your shield surface being the same as your hull surface, you really just need a single mesh; for my purposes this is what I wanted anyway.

Unfortunately, that leaves you S.O.L. if you want to create a .sur for a ship that has any sort of concavity, which is nearly every ship in existence. However, I noticed that some objects in the game, such as turrets, had multiple surfaces in the .sur file, each with a single mesh. Furthermore, hits against any of those surfaces would count against the hit points of the object, as though all were part of the root component. This is exactly what I was looking for, so I tried splicing together a bunch of my single-mesh .sur files into a single, larger .sur file. Of course I had to match names/crcs of names for each surface with components in the target .cmp file, but those components did not need to be anything meaningful (I just used a bunch of small cubes for my components).

It was partially successful. However, this ended up being due to the radii for the surfaces not being set correctly (by the way, it seems that the radius value in the surface definition relates to ship collisions, while the radius value in the bit header relates to projectile impacts). After making these values large enough, hits and collisions registered 100% of the time. I even tried flying the ship with the new .sur into itself, and it bounced right off no matter where I hit.

And now for links to show you folks what I'm talking about:

This is the .sur file for the ship (it's an Imperator, if that wasn't obvious). It is made up of eight convex parts, though I may go back and add a few more. All parts were created from MS3D boxes; in some cases I mirrored them across the z-axis and welded the two halves together. Still, they are all very simple pieces individually.
teh .sur file, viewed in MS3D

This is what the .cmp looks like in utf_edit. The main point is that there are a whole lot of components, though as I mentioned before all but the root component are just small cubes located at 0,0,0. There are 18 components (Root plus 17 zomgbayz) here but as I said the .sur currently uses only eight of them.
The .cmp tree in utf_edit

This is the .cmp + .sur viewed in HardCMP. The .sur is a pretty close fit so it's rather of hard to see, but that's kind of the point. The zomgbayz are all in the same place, circled in red. Since they are in the middle of the model you will never see them normally.
Teh ZOMGBAYZ. And the rest of the model.

Lastly, me showing off that the .sur really does work. Note how the projectiles are impacting exactly on the surface of the top superstructure, neck and bridge.
Zomgbay haxx, surface hits


And that is that. It may not be the most streamlined of processes in the universe, but it definitely works. Once I make my .sur splicing utility a bit more user-friendly I plan on releasing it here; hopefully it will make it easier for anyone to create accurate hit boxes.

Also, I must thank those that have gone before me and figured out much of the complexities of the .sur format and put together an exporter for MS3D. Building upon the insights and breakthroughs of others is what keeps a modding community strong, and I would say we have done a very fine job of that here at TLR.

Edit: The utility can be downloaded here

Edited by - Dev on 6/13/2006 6:35:41 PM

Dev

Post Tue Jun 13, 2006 7:31 pm

Well, after some more dinking around today I discovered a workaround for those folks that want a shield surface outside of the hull (meaning a typical shield bubble). In shiparch.ini there is a line that we all know and love for each ship (this example is the patriot):
shield_link = l_fighter_shield01, HpMount, HpShield01

And if you go looking for l_fighter_shield01, you will find it defined in select_equip.ini:
[Shield
nickname = l_fighter_shield01
DA_archetype = Ships\liberty\li_fighter\li_fighter_shield.3db
HP_child = SpConnect

li_fighter_shield.3db is in turn linked to li_fighter_shield.sur, which is just an average everyday shield bubble.

None of this is new. Also not new is that the shield surface in a .sur files will typically take precedence over the shield definition in shiparch; without a shield definition, the ship won't have shields, but beyond that the actual size and shape of the things like li_fighter_shield.sur don't seem to matter.

But what happens when you don't have a shield surface in your ship's .sur file? My tests with the star destroyer indicated that the game would default to using the hull or the .surs of any equipment mounted on the surface. However, I didn't take into account the size of a star destroyer in comparion to the size of li_fighter_shield.sur.

When I started testing out a TIE defender, which scaled-down is far smaller than li_fighter_shield, I started seeing shield hits well outside my hull. After putting two and two together, I experimentally verified that hits were registering on li_fighter_shield by arbitrarily making it larger and smaller. When I made the shield small enough to be contained inside the TIE, the hull started picking up shield hits, but in all other cases incoming hits landed on the actual shield surface.

So, all one would need to do to produce a shield bubble for a ship is to take one of the default shield .surs and resize it as needed, then link it with your ship through shiparch and select_equip. If you want the hull to act as the shield surface as well, just make the linked shield small enough to fit inside your ship.

Post Tue Jun 13, 2006 11:49 pm

very exciting, and a commendable effort on your part - i can't wait to try this, thank you! and a big thanks to anton and argh and colin and everyone else who have pushed back the boundaries of FL's modability - you programmers and dabblers that have made a real lasting contribution to the community through all your research and programming, we salute you!

Edited by - Cold_Void on 6/14/2006 12:51:04 AM

Post Wed Jun 14, 2006 1:22 am

i'm confused by this step:

The next step is to prepare the .cmp file that you are building a surface for. Import the .cmp into MS3D and add some new dummy groups (I chose to add small cubes to the center of my model and put each in its own group). Be sure to name these new groups something unique so that there are no clashes with models in other .cmp files. You will need at least as many new groups as the number of surfaces in the .sur file minus one, but there is no harm in adding more. Once you have done this, export the model and set the number of groups equal to the number of surfaces in the .sur file. Set the quantity of groups in Group 1 to however many were in the original .cmp; all the other group quantities will be 1.

theres no reason not create your sur groups with the names of the _actual_ groups - provided you have a multigroup model, instead of dummys is there? as long as you have one sur-part to one mesh-Group it should work the same, provided you export your cmp as individual mesh groups - in other words, the dummy files are only necessary if you have a 1part model?

the reason i ask is because i'm very interested in the possibility of setting up new {CollisionGroup}'s for destructible components - if we use dummies it will be destroying those dummy meshs instead of the corresponding ship parts, i suppose

also, i have been getting frequent 'unrecognized part info in sur' errors with the regular exporter surs - anyone else have that experience?

Dev

Post Wed Jun 14, 2006 1:51 am

Sorry I didn't clarify that. All that matters is that you have one .sur group per .cmp group, so you are correct in that if you have actually broken your ship's model into parts then there is no need to add dummy ones. As far as I know there should be no trouble with making some of the ship's pieces destructible, although I have not personally tested it yet.


"also, i have been getting frequent 'unrecognized part info in sur' errors with the regular exporter surs - anyone else have that experience?"

What is the thing that is giving you that error message?

Post Wed Jun 14, 2006 2:25 am

shield bubble type surs cause it at random times, apparently not related to any collision events - i will have to recreate the error to get a precise quote since i quit using the custom sur i made and i've cleared my flspit log several times over since then

testing: my first attempt failed - i was trying to create a valid sur for a large and asymetric gun - anyways i need to get to bed, but i'll be back at it tommorrow probably working on a less ambitious station or ship sur

Edited by - Cold_Void on 6/14/2006 3:28:10 AM

Dev

Post Wed Jun 14, 2006 2:48 am

Usually the safest route is to keep the individual parts as simple as possible. For example, this working TIE defender .sur was spliced together from fourteen different .sur files (one sphere and thirteen boxes). Additionally, physical collisions seem to be very reliable with the first component but are sometimes unreliable with the other components, especially when shields are down; if you want to cover all your bases, make the first component something that covers a good portion of your ship's volume. As I've said elsewhere, projectile impacts always seem to work whether shields are up or down.

Dev

Post Sun Jun 18, 2006 3:48 pm

For those that found the instructions in the readme insufficient, I have written up a more extensive tutorial here.

Post Mon Jun 19, 2006 3:53 pm

*sucessful example*

recognizer.sur
recognizer_cons_fix.dat
15000
1000000 1000000 1000000
root.sur Root
Star_bridge.sur Star_Bridge
Port_bridge.sur Port_Bridge
Star_shoulder.sur Star_Shoulder
Port_shoulder.sur Port_Shoulder
Star_pillartop.sur Star_PillarTop
Port_pillartop.sur Port_PillarTop
Star_filler.sur Star_Filler
Port_Filler.sur Port_Filler
Center_wedge.sur Center_Wedge
Center_filler.sur Center_Filler
Bottom_rack.sur Bottom_Rack
Bottom_wedge.sur Bottom_Wedge
Star_leg.sur Star_Leg
Port_leg.sur Port_Leg

joy! now to add collisiongroups

btw: in the tutorial what SUR exporter build is that? 1.1 has directx mesh reduction, or at least the one i have does - i find disabling it is more trouble than the option is worth(you have to disable it every time) and i'd like to have the build you've got

thanks for this awesome app- if only the fixes you've found could be implemented in the sur exporter... but this is easy enough

p.s the sur created isn't always spatially-accurate although i may just be messing up, so always check the sur in hardcmp afterwards i guess

Edited by - Cold_Void on 6/19/2006 9:14:22 PM

Post Wed Jun 21, 2006 12:56 pm

joy has been diminished by improper radius on spliced sur and a strange deflection that occurs whenever i get near it - its like being buffeted by a really strong wind! any ideas for a fix are highly appreciated

Post Wed Jun 21, 2006 1:06 pm

@ CV, have you got destructables working with this, I've got a very basic SUR from this but haven't been able to get anything else.

**shuffles of with a new headache**

Post Wed Jun 21, 2006 1:59 pm

yup



this is the recognizer from tron, *spoiler alert* i'm designing a tron world for inclusion in my mod - actually i'm building a host of weird systems, but working alone with little knowledge in actual AI coding, doing all the modeling, and everything else means it's going slow - but tron world has three of the five vehicles seen in Tron the movie anyways, i've made collision groups and they work beautifully - this was the perfect model for it since it was very simple to make and thus very easy to make surs for

Dev

Post Wed Jun 21, 2006 8:28 pm

"joy has been diminished by improper radius on spliced sur and a strange deflection that occurs whenever i get near it - its like being buffeted by a really strong wind! any ideas for a fix are highly appreciated"

The solution to the first one is this:

recognizer.sur
recognizer_cons_fix.dat
15000 <-----------
1000000 1000000 1000000

Unless your ship is 15 kilometers in radius, this number is way too big. In addition to determining the sphere within which hit detection is performed, the radius is also used by the game to determine distances between ships (according to your HUD). Start with a radius that is roughly the size of the longest dimension of your ship first, and then if you're not picking up some hits then increase it until it works all the time.

For the second issue, I have a few ideas. First off, your inertia values for the ship are quite large, so if you're hitting the .sur with a normal ship you should expect to go flying (100 would probably be considered normal for a fighter-sized ship). However, since it sounds like you're colliding when you shouldn't be, I will venture a guess that you're hitting with your shield surface earlier than you expect. Alternately, if the Recognizer is physically a small ship, you may be hitting its default shield bubble (refer to the second post in this thread). If it isn't a shield issue at all, I don't have an immediate answer for you.


"btw: in the tutorial what SUR exporter build is that? 1.1 has directx mesh reduction, or at least the one i have does - i find disabling it is more trouble than the option is worth(you have to disable it every time) and i'd like to have the build you've got"

Let's see... it says that it's 1.0.0.2, which does not seem to be the version hosted at TLR.


"the sur created isn't always spatially-accurate although i may just be messing up, so always check the sur in hardcmp afterwards i guess"

I've never seen this happen, it's always dead-on in HardCMP. It's possible that it's related to our different versions of the exporter, though it's probably something else.


"if only the fixes you've found could be implemented in the sur exporter..."

I've pondered this, and if I get the time to deal with it in the future I'll go ahead and do exactly that.

Post Wed Jun 21, 2006 9:08 pm

working recognizer collisiongroups

the buffeting has gone away after switching to another sur model build

i should have realized that was a radius control (should have read the directions more carefully heh)

about surs:
1.modeltool can't resize them correctly, but thats not new - it's always done that
2.i've found that i can make a more complex sur part by deleting faces from primitive cubes and joining them together by regroup/snap-to-grid/& weld - i've had sucess using up to three joined cubes like that - i had 0 sucess using surs with multiple meshs

Dev

Post Wed Jun 21, 2006 9:43 pm

"1.modeltool can't resize them correctly, but thats not new - it's always done that"

*cough* Yes... written back when I was young and foolish, but it still works quite well all the same.


"2.i've found that i can make a more complex sur part by deleting faces from primitive cubes and joining them together by regroup/snap-to-grid/& weld - i've had sucess using up to three joined cubes like that - i had 0 sucess using surs with multiple meshs"

Several parts of the star destroyer's .sur above are made from boxes joined in such a fashion. I probably should have mentioned that somewhere. Anyway, this leads me to believe that the arrangement of triangles counts somehow, and the default objects in MS3D have this correct arragement for the most part. However, this is mostly conjecture based on what I have seen work vs. what I have seen fail; there could easily be something else involved.

Edited by - Dev on 6/21/2006 10:44:27 PM

Return to Freelancer General Editing Forum