CMP to SUR Conversion Tests

Xarian_Prime wrote:
this is the type of thing i’d be looking at a formfitting sur for…

Good example, Xarian. Thank you.

If you build your cmp in parts then the SUR Builder should follow the outline of the parts.

Philosophically, a simple shape around the spines seems more “correct”, to me, than a form-fitting SUR. The purpose of a SUR is to approximate the shape of the ship with a minimal number of polygons, in order to reduce the calculation burden on the engine.

A SUR that requires a lot of polys to enclose a complex shape defeats the purpose of the SUR.

For a station, or an enormous cap ship, a SUR that approximately follows some of the spines might make sense, so that a fighter could fly between the spines. But, for a fighter, a simple shape is more “correct”.

Also, if the ship has a shield, then the hit area should be more like a bubble than like a spiny shape. So making a form-fitting SUR is actually less realistic, in that case.

Have you tried the SUR Builder on that ship? I have a similar test model, but the cmp is made in a single part, so the SUR Builder makes a simple envelope around the tips of the spines (which is, from my POV, “correct” ).

She’s all one piece atm… so yeah i got a pretty big block basically… works ingame well enough for collision proposes (you’d hit a spike anyway at that part of ship) but i do have its big sister as well… and that’s the one i’ll most probably need to worry about… All good, just thought i’d give you something a tad out of the ordinary to think about 8-)

Xarian_Prime wrote:
just thought i’d give you something a tad out of the ordinary to think about

Yes, thanks. Your Shadow fighter is a perfect example of a point that I tried (unsuccessfully) to make earlier: A simple outline SUR is more “correct” for a fighter-size model than a form-fitting SUR.

When you do the “big sister” ship, can you group the CMP into parts? Then the SUR Builder should be able to follow the outlines of the groups.

Remember, the SUR is intentionally approximate. You would not want a SUR to look exactly like the CMP… the SUR should have the absolute minimum number of polygons that can roughly approximate the shape of the model.

More Polys = More Lag

Nah, that’s a Crab Cruiser - in my mod it’s around 300metres across! So it can’t have a big envelope!

StarTrader wrote:
in my mod it’s around 300metres across! So it can’t have a big envelope!

Right, so, as I said, just break the model into parts.

Is there any problem with that approach?

But, for a fighter, a simple shape is more “correct”.

it depends on the univers …
for SW, the shield is a projection between the atoms of the hull
so it needs to be the more accurate possible
the less polygons with the more accuracy …

a question :

when we choose multi part for the sur types we have a pop up who said :

“Multi-Part Sur creation requires model with one mesh per cmp part.”

if we want a more accurate hitbox we need a multi group cmp allright ?
yet i can build a cmp with x groups but still one VMeshLibrary

Is there a link or maybe i don’t understand what “Multi-Part Sur creation requires model with one mesh per cmp part.” means ?

Bullwinkle wrote:

StarTrader wrote:
in my mod it’s around 300metres across! So it can’t have a big envelope!

Right, so, as I said, just break the model into parts.

Is there any problem with that approach?

No problem, that is exactly what should be done. Each of the arms can be broken into smaller pieces so the sur can follow the approximate shape without bridging curves too much. However remember that the sur will only work with the new cmp. And it may take several attempts to get a good-looking one.

Now - it is possible to use a simplified sur with fewer groups with an old cmp as long as the names of the groups in the sur and cmp still match. This will take care to do though, but could help in larger ship surs.

But my point on the Crab Cruiser was that because it is so large it must not have an HpMount sur - the “shield bubble” of the old exporter.

BW - on low-poly surs, you are quite right, people think too much on contour-following and it is not often necessary until ships are very large. It is lost on fighters of less than 10-12 metres in my opinion unless they have booms or fins or large wings or spikes like this one, with big empty space between. Small detail will not be seen in combat.

I know modders like to go to infinite detail on maybe break-offable bits, just as they do with texturing, but who will see that on a ship less than 8 metres flying past at 500km/second?!

But on large ships (and of course stations) where other ships can fly between the booms then it would not be good to have a sur covering those gaps.

I have not made surs for scenery or stations so I can’t comment on the sur builder’s ability there - can anyone else?

Right, I agree with most of that.

One detail, for the sake of clarity for all readers:

StarTrader wrote:
And it may take several attempts to get a good-looking one.

Just to be sure that we are all on the same page here, “good-looking” is irrelevant for a SUR.

The SUR is the computer’s Point of View (POV) of an object. For most things, a blob is all that is required to track movements and hits.

Even with form-fitting SURs, the goal is extremely low poly count. Close-fitting is irrelevant. Looks are irrelevant. We just want an approximate fit that uses minimal polygons.

The rest of your note sounds right to me.

To be honest, I don’t understand the approach of the Sur Builder anyway. To my understanding the problem was a wrong implementation of the sur format which the exporters and the other tools messing with surs use. So why not just fix the tools and let people decide how much polygons they use. There are pretty sophisticated algorithms for polygon reduction already available in many modeling programs. Alternatively you just build your own simple mesh out of some boxes etc.

I would even try to build a .obj->.sur converter, if there was a an easy to understand documentation of the sur format.

Concerning the memory use of the Sur Builder: From my viewpoint, there is absolutely no excuse for using 1,7GB of memory other than broken by design. There are so many ways of allocating memory so that you don’t need to allocate it all on startup. Even then just building a simplified mesh out of some vectors would never need so much memory.

I do not disagree, Schmackbolzen.

However, I will say that the SUR Builder is a convenient tool for making a SUR in a few minutes.

Lack of documentation on the SUR format seems to be the weakest link. Everybody appears to be guessing about it.

The memory thing appears to be due to some library code, but it is not mine, and some of it appears to have been originally written in straight C. I am not allowed to publish the code, so it is not worth a lot of time for me to figure it out, or to update it. The original author has said that he is willing to help, but he has been busy with professional work. Remember that nobody is getting paid for this work, so when the design decision is a choice between “quick” and “good”, then “quick” usually wins!

So it is a cool tool as it stands, but I agree that a reliable exporter would be valuable, as well.

Mirkha wrote:
if we want a more accurate hitbox we need a multi group cmp, right?

Yes.

yet i can build a cmp with x groups but still one VMeshLibrary

Is there a link or maybe i don’t understand what “Multi-Part Sur creation requires model with one mesh per cmp part.” means ?

I believe that you need a mesh for each group. To be honest, I hope that one of the modelers will answer that better for you.

Bullwinkle wrote:
Right, I agree with most of that.

One detail, for the sake of clarity for all readers:

StarTrader wrote:
And it may take several attempts to get a good-looking one.

Just to be sure that we are all on the same page here, “good-looking” is irrelevant for a SUR.

The SUR is the computer’s Point of View (POV) of an object. For most things, a blob is all that is required to track movements and hits.

Even with form-fitting SURs, the goal is extremely low poly count. Close-fitting is irrelevant. Looks are irrelevant. We just want an approximate fit that uses minimal polygons.

The rest of your note sounds right to me.

“Good looking” is in the eyes of the beholder, BW.

You misunderstand me. I’m not talking about sleek and sexy here. I’m talking specifically about a ship like the Shadow Crab Cruiser. A one-piece sur would be bad for such a ship, because it would give it a very large hit & collision surface.

What I’m saying is the cmp needs to be split up into sensible groups and the sur generated may still have bad coverage, or cover several arms, if you understand now - that is a bad-looking sur!

So in such a case the user will need to break it down again and generate another sur until he gets what he is looking for - good looking in this sense.

In the case of the sur builder each group will always have a convex sur part. So it’s not a matter of this, it’s a matter of how well it covers the ship is what I mean, and this is for the modeller to decide.

For my use, if I remember correctly I split the Crab into one group for the body and 1 to 3 groups for each arm. It’s a big ship and I wanted collision detection if a small ship hit one of the arm tips. Then I had to rationalise (reduce and recombine cmp groups) because I had more than 18.

To make the arm sur I used hex cylinders for some closeness to the body, tapered them to follow the arm. I made all the sur parts by hand in this way and spliced it, and I got a very “good-looking” sur!

But - it crashed when tested in my game, so I couldn’t use it! I remade a new sur, but the same happened. Did it again a few more times until I got fed up and resized a standard sur.

There’s another lesson. I suggest all sur modellers make at least 20 surs by hand!

For the Kilrathi Dreadnought I did it the same way, making sur parts by hand and splicing them, and that one worked very well, here’s a shot below.

It’s always intended that the sur should have as few polys as possible. Standard FL uses simple boxes very often, sur modellers should check a couple of standard FL models using the importer and they will see that.

But lastly - you can never dictate minimalism to people that think 4GB RAM should be standard for a Netbook! rofl!

(ADMINS - CAN WE PLEASE HAVE A ROFL SMILEY?!)

“Yes” would have sufficed, but thanks for the detail, StarTrader!

I am having some problems with the Sur builder. So far, I have had very good success in getting it to make multi-part surs for everything I could have dreamt about. However, in the case of some models, the sur builder tends to forget about some parts (that is, meshes).

I have attached two of the cmp files in question, and one sur. Please note that this has happened to cmp files intended for ships as well, both small and large in size. I have played around with all the settings, including duplicate radius. This sometimes had some results (like 6 of 7 sur meshes output instead of 4) but usually to no avail.

Thank you for the report and the test files, BBalazs. I am glad that most of your models produce good SURs.

The SUR builder can sometimes be picky about things such as welding… a CMP may look good to the eye but have some small quirk that the SUR Builder does not know how to handle.

Your terrain model is only 1 group, is that the one you meant to send?

And it’s a long way out from the origin too. I don’t know if that will affect the sur builder.

I can’t see anything wrong with the cm_hill1.cmp file.

Could it be a numbering problem in sur-builder, as all groups are named cm_hill1_n where n = 1 to 7?

It looks good and complete in the preview animation in sur-builder.

I renamed the _1, _2 to _A, _B and re-exported the cmp, ran sur-builder - got 4 sur parts only.

Welded all vertices and re-exported, ran sur-builder - same, only 4 parts.

Tried no Type 1 sort & no Type 2 (got no preview display!) - got 5 parts.

Type 1 sort only - got 6 parts!

Type 2 only - got 5 parts.

Type 1 only & dup radius = 0.1 - got 6 parts.

BW - We have a problem!

Sorry about that. I have attached a smaller version of the terrain file, which in turn includes 5 separate meshes. I get similar problems, only 2 meshes are built using Type 2, sec. no sort, dupl. radius 1.

Edit: attachment added

Since this subject came up, this is a scenery cmp, so the sur type that is generated should be Type 2? (type 2=scenery, type 3 = weapon/damage object, type 4 = ship/station according to FL Model Tool) ??

And on the same subject, the cmp exporter v03 plugin for MilkShape can be set for Ship / Cockpit / Weapon - but no Scenery.

Could these be a factor in the problem, or in the working of the sur in its role?

I thought that that option only determinde how the perts where referenced in the CMP eg ships use Fix for their parts and weapons pris which can be changed through utf editing in the cons part (o btw adoxa if you see this can you put a tool in the utf editor to create fix/pris/rev nodes so that you can say how many parts will be in each node since I have been coming up with problems once I get to around 30 groups when doing it by hand :/) but yes back on topic I think that is the only difference (i don’t know what it is exported as for cockpits). Just looking at some of the scenery models the majority of them are mainly fix but some have pris, rev and even sphere (what does sphere do anyway?) for what i guess is their animations, if you look at manhatten cityscape you can see all four types of cons.

Ozed

Surs don’t have a type, it was a misunderstanding of the format. What was thought to be the type is actually the number of tags within each object (I believe this was covered earlier in the thread).

For example, let’s look at bw_fighter.sur. Here’s the first 32 bytes.

000000  76 65 72 73 00 00 00 40 2d 8f 68 12 04 00 00 00    [email protected].....
000010  21 66 78 64 65 78 74 73 60 7b da c0 3f 6c e5 bf    !fxdexts`{..?l..

```The first eight bytes form the header tag: vers = 2.0f. Everything after that is an object. It starts with the CRC of the name (0x12688f2d = Root; this is zero for 3db surs) and the number of tags for this object (4). Now come the tags. The first is "!fxd", which contains no other data. Then there's "exts", which contains six floats describing the bounding box. The remaining two are "surf", where the bulk of the data is, and "hpid", a list of the hardpoints in "surf". That continues for each object (0xF4082FBD = bw_engine01_lod1 @ 0x3224, 0xFE3AEE4E = bw_port_wing01_lod1 @ 0x356C & 0xF51D449E = bw_star_wing01_lod1 @ 0x3A38), until EOF. [SurDump](http://adoxa.110mb.com/freelancer/surdump.zip) covers all the details.