CMP to SUR Conversion Tests

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?)

Bullwinkle wrote:
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?)

ok, do you mean that each group need to be continuous ?
or the entire model ?
i thought that it was for each group
that the sur builder “draw” a hitbox one after one, so it is not necessary that each group should beside the other

Mirkha wrote:
do you mean that each group need to be continuous ?
or the entire model?

You ask the best questions, Mirkha!

I don’t know 100% of the answer to that.

The Builder attempts to build a convex hull by making successive approximations to the outline(s) that it finds in the model’s parts. I suspect that some models may build correctly without a continuous outline, while others will not. However, that is a bit of a guess.

I would be interested in reports on that topic.

BW is still ignoring the evidence I have put forward, and still accusing me of trying to fool the tool.

I cannot understand why you think that I would want to do that instead of assist to define and identify the problem so that it can be perfected, which is what we all want. We do not want more substandard tools, we have enough of those already as all of the modders here will confirm.

As Mirkha guessed, I did go to great lengths, many hours, over several days, to diagnose this problem and give you verifiable feedback.

Thank you for believing in me Mirkha, it is very much appreciated.

When there is an intermittent problem, the way to find it is to try to isolate it, and make it easily reproduceable.

I have done that for this case.

But you dismiss it. I even tried to avoid that…

The long diagnosis I made was with the ship model. But I needed more definite methods because the ship could be easily dismissed as “faulty”.

But it was a surprise that the sur builder cannot build surs for a series of boxes.

The test file merely narrows down and focusses on the problem, without the possibility of it being “the ship”.

There is no ship, only well-made, welded boxes.

They are formed differently to prove or disprove that the forward angle may make a difference to whether the tool succeeds or not - it does!

An obtuse angle fails, an acute angle works!

They were also placed left and right of the Origin to identify if position makes a difference - it does!

There is no logical reason that it would be OK to generate a sur part for one box but not for the same box when it is moved to the opposite side of the centerline.

Think about this and forget for a moment that you hate and despise me and that you think I am an irresponsible, horrid and spiteful teenager…

Look at the shapes closely, note each shape and its position, whether it had a sur part generated, and where its mirrored or identical twin is too, and whether that had a sur part made.

As you see in the jpg of my test file, the sur builder does build surs for parts that are not attached, not welded to each other, and are not adjacent to each other. That is a VERY positive result of the test file. The large box turned at 45 degrees at the back of the model proves that. And the individual surs at the front also prove that.

Sur builder centers each sur part on the shape it covers, and this is good too - invalidating BW’s comment “how would it know where to place the part”? Clearly, it does, and does it well!

And every box in the test file is properly welded, they are complete boxes.

But in my original model the two wings were not properly welded, some of the vertices were separated, and the wing ends were open - but the sur builder still made a good sur for those wings, only the right tip was not made.

But when I moved the left wing-tip to the right wing (deleting the right wing-tip), it did not make a sur part for it.

Did you understand that?

The only difference is that the part was moved to the right of the Origin.

It is not necessary for ship parts to be welded together, but obviously in a good model they will be adjacent or overlapping if not welded together, otherwise there will be gaps in the model and maybe its textures, not a good thing.

But note - the sur builder can make a good sur for a sphere that is placed between two ship arms without touching them, this is absolutely great - a “plasma” weapon held in place between two booms by “force fields” could now be possible in a model.

I did attach the .ms3d file of the tests too, with the jpg, but it was ignored. So you can make the same tests yourselves that I did.

If you disable the multi-group function of the sur builder you will have destroyed it and LS’s good work.

It will remain a single-sur tool and we already have one that does that well enough.

It will be of no more interest to me, but somehow I don’t think you will care.

After all I believe you think I am an irresponsible twerp bent on discrediting you, or having a laugh at your expense, rather than the opposite, of trying to assist you by spending a lot of my time investigating this and developing a method to isolate the problem, to identify the exact problem, so that you or LS or someone else can debug it and make it the great tool that it can be.

But it’s in your hands, it’s really too much effort, and you ain’t about to let it get better if you can help it, are you.

I wish someone else had taken this on, I really do. As far as I can see right now this superb tool is lost to us.

to progress : Bullwinkle can you make a very simple model like a tie ?
i mean by your own, two sphere + 4 rectangles
less simple will be difficult ^^
and try to make a sur

at the end i think we’ll need a tutoriel with all we need to do and especially what we must not do

at the end, the sur builder is to make multipart sur
as StarTrader says, if it’s only for one group hitbox we can easily done that in milkshape

this tool, for me, is dedicated to replace the sur splicing method
maybe not as acurate than the sur splicer but not so far

can you ?
that maybe can identify if the sur builder treat each group one by one or as an entire model

okay, first of all, ST, stop trolling. you just provoke BW to troll back, that won’t help anyone. BW, don’t take critiques personally, if we report issues, no matter how much, mostly theire supposed to help rather than to disrespect someone.
okay, that being said.
i think we need to pay attention on ST’s investigations, as, if he sais the truth, and shapes are not surred correctly depending on their coordinates or angle, this is not a feature anymore and clearly has to be fixed. ofc, approximation is good, but we can splice approximate surs so what would we need a tool for, if it does deside to build or not to build on its own?
now, to OP’s method. unfortunately its limited to ten model groups, do work or do not work almost randomly and are in this way inefficient for larger ships. moreover i experienced that the random unability of model parts does only appear when you use the ships as solars (sattelites in my cases), while, when you fly them, all parts work just great.
another problem is, that the whole model is streched to the very edges of the mesh by resizing. small parts like a forward gun, if modeled, do sometimes cause unfitting sur shapes. this likely can be avoided by sizing it with the modeltool by factor one rather than by cmp model. in that case it is necessary to have put the model where the ship is, too, if the ship is not centered.

the splicing method is btw very similar, but with one difference: while the ship works fine as satellitte, with both, collisions and shots, most parts are disabled when you fly it (maybe all except for the first?) to collisions, however do detect all armament hits.

StarTrader wrote:
I believe you think I am an irresponsible twerp bent on [something]…

I do not know your reasons for ranting, but I do listen when you effectively communicate a valid point. I certainly respect your experience.

However, I cannot do anything about a phantom that I cannot reproduce. Can you show me a valid model that fails? One that does not include the issues that we have discussed?

StarTrader wrote:
I wish someone else had taken this on, I really do.

So do I, StarTrader.

So do I!

@Mirkha: Actually, I cannot make a model. I don’t even have the tools. I am dependent on you modelers for test objects.

Are you having trouble making a SUR for a Tie Fighter using the single-part method? As I have pointed out several times, the computer does not care about the wings. Hit detection is based on a probability of a hit, so a sphere or a cube will produce very nearly identical results in-game. I would be surprised if you could tell the difference during normal game play.