CMP to SUR Conversion Tests

Gisteron wrote:

1. the amount of sur polygons is far too high and lets ignore that some pc’s get stuck for hours due to its resource consumption.

2. honestly, we won’t get a proper automatic sur creation tool. there will always be a model that will be surred differently than the artist wishes

In general, YES, that is exactly my point, Gisteron.

Two minor details:

1. The default Single-Part SUR created by the SUR Builder uses far fewer polygons than Multi-Part. Single-Part SURS should be a good compromise for most purposes – both novice and expert.

2. We will not get a PERFECT automatic SUR creation tool. But I think that the current SUR Builder does a “proper” job for most purposes.

Mirkha wrote:
thanks Bullwinkle, but in my case, star wars ships, i assure you that for the moment one group sur is not good
imagine a x-wing or a tie like this :

Your pictures do not display, Mirkha. You might try attaching them to your message.

However, I know what an x-wing and a tie fighter look like, so I can imagine what the single-part SUR would look like. And, from the computer’s point of view, I can tell you that the single-part SUR will be just fine.

You are looking at this the same way that StarTrader is; from a human POV. And that is simply not the intention of a SUR.

A SUR is the computer’s Point of View, and the computer does not care what your ship’s wings or accessories look like. The only thing the computer cares about is a blob in space that is quick to calculate. Hits are very approximate, so the precision of the SUR is unimportant.

If you want your wings to be blown off, then you will need to create your CMP in parts. In that case, a multi-part SUR will be fine.

But the single-part SUR is more than sufficient for the vast majority of models.

EDIT: A single-part SUR would even be OK for an Imperial Cruiser in most situations. An exception might be if you want to be able to destroy the shield generator bubbles behind the bridge, then you might want to create a multi-part CMP and SUR.

Another exception would be if you want to be able to land on the rear of the bridge superstructure (as Han Solo did in the Millennium Falcon), then you might want a shrink-wrap SUR.

Otherwise, the only thing that matters is that you can hit the SUR with your weapons and you bounce off if you get too close.

so here : http://img256.imageshack.us/img256/5662/tiecomp.jpg

for fighters you’re right i agree, the combat mod in freelancer is not really accurate … we always try to shoot the center of the ship
but i think also about the capships,

http://img101.imageshack.us/img101/9498/nebbcomp.jpg

the same, at the left with surbuilder and at the right by hand

excuse me, but for me human or computer pov doesn’t mean anything
the only point of vue i can take in consideration is the players point of view
and the players want to flight near a capship, to be “closer to the action” if i can say

and i don’t talk about who want to fly through a base
http://img138.imageshack.us/img138/3397/depotcomp.jpg

Mirkha wrote:
to fly through a base

Maybe ImageShack is down… your pictures still are not working.

However, as I said in my edit above, a single-part SUR is adequate even for an Imperial Star Destroyer, unless you want to land on it. Remember, a Star Destroyer has a shield, so the actual “hit box” is a bubble shape!

If you want to have more detail, then you can have it. It just takes more work, to make your CMP in groups.

Either way, the SUR Builder is easy to use (or will be somewhen).

As for flying through a base, yes, that is a case where you will want your CMP in groups and you will want a multi-part SUR. It is an “advanced” model, but it can be done (and has been done).

Bullwinkle wrote:
Remember, a Star Destroyer has a shield, so the actual “hit box” is a bubble shape!

no, in SW, the shield is a projection between the atoms of the hull
as you can see in the Empire Strike Back, the millenium falcon is able to pass very close to the isd and stick to it
for example

anyway i have my answers, thx

Mirkha wrote:

1. in SW, the shield is a projection between the atoms of the hull

2. as you can see in the Empire Strike Back, the millenium falcon is able to pass very close to the isd and stick to it

1. OK, that is consistent with some of the action in Star Wars, such as shooting off turrets and shield generators. Cool.

2. Yes, that is what I meant by “landing on the back of the superstructure”. As you say, that effect would require a close-fitting SUR.

LancerSolurus wrote:
The sur builder requires a minimum of 5 vertices to even attempt to build a sur.

I assume that you mean 5 vertices per group? That might explain the leading tips of StarTrader’s Goran Wings.

Thanks, LS, I will add that to the documentation.

OK, stop, forget all of the above bloody nonsense!

I have made many tests including remodelling my ship more than 30 times, but we don’t need those.

It’s not to do with the ship. It fails to generate sur parts for boxes too. (And Bbalazs’ model had no sharp shapes either, all soft spherical).

Here is the problem better defined…

---

1. From 14 simple box shapes with 8 vertices each, only 6 boxes had surs made! This is the problem that needs fixing.

---

2. Secondary issue: The fin of the Goran test ship as you may remember, the forward vertex of the base is missed when the sur part is generated. The fin base is open but the wing ends were also open and those were generated correctly.

That is not a modelling problem, it is sur builder not reading all vertices, and this could be part of the 1st problem.

---

3. Bullwinkle, I have had it with you, don’t offend me any more, you have done that enough already and I’m really not a nice guy when I am goaded to the limit.

I am not trying to fool the tool, I need to understand why something happens, and I go to great lengths to get to that, instead of pooh-poohing it as ST’s or someone else’s whims because I am so overproud of the little that I have done and don’t want to do more, or don’t like the thought that something I have made isn’t 100%.

LS got the sur builder to where it is and it needs a little more debugging. Why ruin it for him and everyone else too?

Sur Builder does have a fundamental problem and it took some defining, because I was foolishly over-convinced that it was a problem in the model.

There is a formula / calculation problem in Sur Builder. It does not generate surs for certain simple boxes, dependent on where they are located in respect to the Origin.

So either get some help to fix it or dump it to someone else who is prepared to put in the effort, and stop trying to shift the focus on to me, I can simply throw the towel in and find better things to do with my fing time than play "dodge the sht" with you.

You seem to want to do the absolute minimum. That is not acceptable if you have taken on this project for everyone.

And as for telling them it’s the way they are doing it, or “they don’t need it”?

Bullshit!

Don’t want it /can’t be bothered? Give it to someone else who can and will, so others can get the benefit of a good tool.

A box sur around a small ship is fine, the distance from the hull is minimal. But on a huge ship of thousands of meters, the detection will be hundreds of metres away from the hull and that is not acceptable.

You seem to not want to understand that the problem is a huge problem for big ships when the sur builder makes surs with F*ing great holes in the detection. It will be useless as a tool. Get your head around it.

Thank you.

–------------------------------------------------

Files attached below.

Once Sur Builder can generate the sur part for every box in this file it should be able to generate for every shape too.

Note - I have not tested for vertical position of shapes, there may be room for testing that too.

It also fails with “fat triangle” shapes too - I use a box with two corners welded together to make one. Those have 6 vertices each.

And again it depends on which side of the centre-line that the shape is on.

So there could well also be similar problem in vertical position of shapes too.

OK, so let’s recap:

• The majority of test reports are successful.

• The shape of the SUR makes little difference for small models, since hit calculations are based on a percentage probability of a hit. The main concerns are SUR size and whether the SUR works in-game.

• Shape does matter on some larger models but, even then, low poly count is more important than the exact shape.

• Bejaymac pointed out that single-vertex “points” do not work properly in-game. He added that “knife-edge” shapes may not work, either (such as your six-vertex shape that cannot be made with any real material). My suggestion: Use 8-vertex trapezoidal prisms, with some of the vertices close together. That is a more realistic shape, anyway:

• Lancer Solurus said that shapes need a minimum of 5 vertices, and Cursor demonstrated that some shapes may need even more vertices than that (tessellation).

• Cursor demonstrated that closing your fin shape and tessellating satisfies the builder.

• We have yet to see a correctly-made model that produces a SUR that is “hundreds of meters away from the surface”.

• Your 14-box model demonstrates that shapes must be properly welded in order for the SUR Builder to follow them.

The above points cover all models and shapes that we have discussed.

It is not a matter of “wanting to do the minimum”. It is a matter of “I cannot fix something that is not broken”.

(However, you are partially correct in that I am reluctant to invest hundreds of hours in sparsely documented code that I can neither publish nor reuse. Especially when that investment would not provide a real benefit to anyone.)

What I can do – and have already begun to do – is to create a Forge repository for Lancer’s projects and to invite a couple of developers to participate in continuing to maintain them. I have not announced this because it is not finished, but I just wanted you to know that we are doing the things that can be done… and that I am not the only person involved.

OK, sorry for my grizzly moment, I was very disgruntled.

But - I do want all shapes to have a sur part generated, they do NOT have to be welded together, this has been proven.

There IS a bug in sur builder as described above, it is very easy to reproduce, and that does need fixing. I think when that is found the sur builder will be one of the most useful tools available. It IS a very important tool and should be as good as it can be.

The failing shapes in the test model are identical to ones that are detected and “sur’d” correctly, but in different locations, hence indicating a formula problem.

When the builder can detect all meshes in a model cmp without missing them accidentally as it does now, then it may be beneficial to issue a message when a mesh will not have a sur generated, e.g. if it has less than the requisite minimum vertices or when there is a knife-edge that will probably not work correctly in-game. Then the modeller can address those parts hilmself fairly easily.

As I said before:

the above points cover all models and shapes that we have discussed… I cannot fix something that is not broken.

You keep trying to make your SUR look like your model, and that is not what a SUR is for.

Consider this: The game already has 3-D models, so why is there a need for SURs? SURs exist because the 3-D models are too complex to calculate. The entire purpose of a SUR is to approximate the model with a minimum number of polygons.

Furthermore, hits are calculated as a probability, because that is a much quicker calculation than doing the precision math that would be required to, say, shoot a turret off of a station from several thousand units away.

Because hits are calculated as a probability, the precise shape of the SUR is unimportant.

Every additional polygon that you add to your SUR increases computation burden, which will contribute to lag and/or diminished frame rates on some systems.

An ideal SUR would have no more than a few dozen polygons. Many objects only need a single trapezoidal prism (6 polys / 12 triangles):

Or perhaps an icosohedron (20 polys):

This is why the default single-part SUR is ideal for most purposes.

Granted, there are some models that benefit from more refinement. You can make the best possible SURs with the SUR-splice method, using a few basic shapes.

The SUR Builder will never build SURs that are as elegant as the SUR-splice method. However, the SUR Builder makes decent approximations, in a matter of seconds, which is an excellent time-saver. The precise shape of the SUR is not important, as long as the SUR is approximately the right size and works in-game.

In other words, it’s a feature; not a bug*, StarTrader.

(*) thanks, Cursor!

OK here’s my last post on this subject.

You are still on the same tune, eh?

A big box sur as you describe for a ship the size and shape of the Shadow Crab is useless as a sur because it covers more empty space than the ship occupies.

A small fighter would collide with emptiness in empty space 100m from the ship hull. But that’s OK, after all BW says so.

What language can I communicate with you in?

You’ve spent more time enforcing your view than it would have taken to verify the problem does exist and the builder OFTEN does not generate surs for a simple box that it has ALREADY made a sur for a similar one.

Have you even looked at the jpg of the 6 surs out of 14 that should have been generated?

Those are in red, the dull white ones are the original shapes that do not have sur parts.

They should have.

They all have 8 vertices, more than the required 5 - but are still not generated.

Oh, but again I forgot - it’s not a bug, it’s a feature!

This is how we make a LIGHT sur - leave HOLES in it!

Have you even opened the ms3d file I attached?

Have you tried to generate the surs from it and verify that ONLY 6 MESHES ARE DETECTED FROM THE 14 IN THE FILE?

That means that 8 are NOT made.

They are all identical or similar, so if 1 is made they should all be made.

Oh - hang on, that’s illogical!

Since everyone else here agrees that it is fine, it must be me that’s wrong.

When it can make some meshes just fine, but not other identical ones in the same model?

Isn’t it ODD that a mesh on the LEFT of the Origin is sur’d correctly but the same mesh on the RIGHT is MISSED?

And sometimes the opposite?

Ah! Sorry! Right, yes, I see what you mean - it’s a F*ING FEATURE!

To me that is a 6/14ths (approximately 40%) success rate.

In other words, a failure.

As it makes some boxes but not others AND LEAVES BLOODY GREAT GAPS IN THE SUR!

It is broken, in any language - except yours.

It is so close but broken.

But you are still in denial.

WTF do I say next?

Let me think….

“I must be stupid”?

Yes, that’s it!! GOT IT!

It’s not broken, BW says so.

I need medical attention.

Another utility that’s useful about 50% of the time. And useless the remaining 50%… and has so many needs for get-rounds…

So easy to fix, if only…

But…

Nah, I’m stupid - things aren’t like this in real life, 40% is a SUCCESS!

No fix is needed.

Only my brain.

Let me say it 100 times, I think I’m getting it…

I must be stupid. I must be stupid. I must be stupid. I must be stupid. I must be stupid. I must be stupid. I must be stupid. I must be stupid. I must be stupid. I must be stupid. I must be stupid. I must be stupid. I must be stupid. I must be stupid. I must be stupid. I must be stupid. I must be stupid. I must be stupid. I MUST be stupid…

Only I am saying that 6 out 14 is not acceptable, nobody else is having any problems with that.

So No fix is needed.

Only my brain.

Let me reconsider this one more time…

I made 14 boxes, all with 8 vertices each, and different shapes to see where the break might be if it is a calculation on angles…

Some were built fine, but other identical ones were not built at all…

Ah, Got It - the sur builder has Alzheimer’s!!

No, it’s me that has Alzhemer’s…
… I must be stupid. I must be stupid. I must be stupid. I MUST be stupid. I must be stupid. I must be stupid. I must be stupid. I must be stupid. I must be stupid. I must be stupid. I must be stupid. I must be stupid. I must be stupid. I must be stupid. I must be stupid. I must be stupid. I must be stupid. I must be stupid. I must be stupid…

Getting there…

Since you continue with this there is no point me expecting anything sensible.

And I think the fix is easy once it is pinned down it’s merely a matter of… stepping through the builder and seeing where and why it decides to miss out an entire shape that it has just already made once for an identical model part in the same cmp file…

But - where can we find someone who is BOTHERED to investigate a little?

Nah, it’s me, I’m stupid… I must be stupid. I must be stupid. I must be stupid. I must be stupid. I must be stupid. I must be stupid. I must be stupid. I must be stupid. I must be stupid. I must be stupid. I must be stupid. I must be stupid. I must be stupid. I must be stupid. I must be stupid. I must be stupid. I must be stupid. I must be stupid. I must be stupid. I must be stupid. I must be stupid. I must be stupid. I must be stupid. I must be stupid…

Is that 100 yet?

Yes, you hit the nail on the head, StarTrader!

But, seriously, I don’t think you are stupid. I just think that you are not thinking about what a SUR does. You have this idea in your head that your SUR should look like your model, and that is just wrong. Look at the vanilla SURs… they are very rough approximations made with a bare minimum of polygons.

If I understand you correctly, you want me to invest upwards of a hundred hours so that you can:

A) Build SURs for models that do not work correctly in-game.

2. Build SURs that function approximately the same as SURs that the builder builds now. The only difference is that they will look different in MilkShape.

Have I got that right?

Regarding Number (2), I am not sure that it is possible for the builder to guess what you want when you have objects that are just floating in space. How would the Builder know the right way to connect the pieces? No matter how much time I invest, it is not possible for the Builder to guess how to handle all of the crazy ideas that you seem capable of coming up with.

And, BTW, how does a model like your 14-box model render in-game? I’m just curious…

Automated tools must follow rules of some sort. In the case of the SUR Builder, the rule is that your optional multi-part SUR requires a well-constructed CMP.

I do not think that is an unreasonable requirement. In fact, I cannot think of a better rule.

Listen BW:

This is a very important utility to complete properly, and it is not far away. After so much effort it’s a shame to not finish it.

You just can’t be bothered, that is the simple answer. You want to sit on your laurels.

The 14-box test model is just that - I analysed and remodelled my model and discovered the shapes that the builder does not like, then removed the ship so that you could not say it’s the ship model.

The test model is to demonstrate that it has a problem, and where the problem is. Many ships are made of boxes. It will make a balls-up of them.

It cannot generate surs for several instances of the same simple box reliably. Just 12 polygons. It leaves gaps in surs where other smaller ships will pass through. It cannot be used for bases either while it does this.

That is IT.

It is almost USELESS until it can.

Anyway I have really had it, you are just unbelievable.

I just hope others confirm you are in the wrong, if not then everyone will be very happy.

dear ST, don’t you think, if most of us, and we mean here really most, exceptions are singular, are happy, that BW is in wrong only cuz you are such an exception? do model your surs yourself, use sur splice or the crossfire method, if you don’t like the builder. the builder is a simplified tool, mostly either for small ships or for lazy asses, not for beautiful, perfectly fitting surs. you just miss its purpose, and for its very purpose it is just good. not perfect, yes, but just fine.

You know what, Guys if it make anything better. Once i get far enough into my programing degree to understand certain codes and crap, I MIGHT ask Lancer to get the code for this sur builder and twwek with it.

StarTracker, I AGREE with you in saying THIS BUILDER IS NOT 100% COMPLETE, heck i’d only say its 60% complete. And until we know more about HOW A SUR FILE WORKS It may never be close to 100%.

Bullwinkle, I’m not siding all the way with ST, Its just that there is only so much that one person can or can not do. And you Sir have gone above and beyound.

BUT I also feel that there is two peoples work here and that they differance in the code is what MIGHT be casuing the errors. You may have to just BITE the bullet and shift though what to you seam to be worthless and disorgnized. Maybe that what is needed to do.

BECOME THE BORG, Bring order to the chaos, make the program one voice, one being, make this like the Borg! . . . . . . Well without the assimulating others and other programs please!

Bullwinkle wrote:
You have this idea in your head that your SUR should look like your model, and that is just wrong. Look at the vanilla SURs… they are very rough approximations made with a bare minimum of polygons.

no, StarTrader says that a simple model with simples shapes it is not processed correctly by the tool
he doesn’t talk about a perfect sur, he talks about missing parts in the sur

as i said above, event in SW, although this does not correspond to the technical reality of the universe in question, a bubble around fighters is largely enough.

ok, but the tools is also dedicated to build multi-part sur no ?
if no, deactivate the function.
if yes, missing parts is not acceptable.

I have no idea of the problem and I have no idea how to solve but i can know if missing parts is good or not

think about one thing, time is the more precious “commodity” in the entire univers
you cannot store it, you can only spend it
StarTrader takes a loooot of time to work on the model to help all of us and that means also you to build a better tool

and if i understand well, this is a random bug
despite all the respect i have for your work, i will not use a tool that generates a “random” hitbox

as i have allready said, if the sur builder is not dedicated to build multi part sur, deactivate the function and that’s finish

Thank you, guys, for your comments.

@Gisteron: Yes, you continue to have the balance right: If you don’t like the SUR Builder’s results, then use another method. Thank you for suggesting OPR8R’s SUR method. It is a promising-looking tutorial.

@ST: I would be interested in a second opinion about OP’s method. It looks good to me, but I do not have the right stuff to test it.

@Lonestar: Yes, incomplete documentation of the SUR format prevents a 100% solution.

@Mirkha: +1 for the suggestion to disable multi-part SURs. That is my favorite solution so far!

StarTrader says that a simple model with simple shapes it is not processed correctly by the tool. He doesn’t talk about a perfect sur, he talks about missing parts in the sur.

Yes, that is what he says. If that were the full story, then I would be interested in pursuing it. However, take a close look at his 14-box model (below). I am surprised that the Builder found as many of the parts as it did.

The truth is that every anomaly submitted in this thread has been traced to an issue with the model. The SUR Builder cannot read the mind of the modeler… it can only follow a continuous shape. Like any other computer tool, “garbage in = garbage out”.

Tips for preparing a model for the SUR Builder:

• Make sure that there is a continuous shape for the Builder to follow. Weld seams and close shapes that do not build properly.
• Add extra polygons for shapes that do not build properly (tesselate).
• Use one group per mesh (what is the best way of saying that?)