CMP to SUR Conversion Tests

Gisteron wrote:

1. problem is not the creation of additional polys. problem is, that noone knows where to add them

2. what we mean here is definately not a feature but a bug

3. we criticise only your refusage

4. we do almost not see any results, almost no improvements.

5. don’t you take it personally

Thank you for posting a thoughtful message that I can respond to, Gisteron.

1. We have discussed this many times. Shapes without enough vertices sometimes fail. Therefore, if a CMP part fails, and it has very few vertices, then create more vertices (avoid pinpoint 5-vertex and knife-edge 6-vertex shapes; split faces if necessary; more than 8 vertices may be required). OK?

Here is the process:

a) Create model.
b) Build SUR.
c) Check SUR.
d) If a part does not build correctly, then check for enough vertices. If the part has very few vertices, then add more vertices and re-build.

Most models only need a-c.

2. It is not a bug. No amount of flaming or ranting or intentionally insufficient test cases will make it a bug.

As Lancer and I have explained several times, it is the way that the convex hull generation part of the Builder works, along with its associated limits.

We do not know the exact limits yet, because nobody seems interested in answering my questions.

3. I refuse nothing. I have done (or am in the process of doing) everything in my power to preserve Lancer’s code for the future; for the benefit of the entire community.

4. When I got the SUR Builder it did not work at all on the majority of models. I fixed several real bugs before releasing it. All that is left to do is some documentation and further cleanup of the user interface.

I have no plans to add new features, or to change the way that current features work. The tool seems brilliant as it is now. If somebody else wants to work on it, then it will be on the Forge. I have already invited a couple of other developers. So far, nobody has been interested.

5. I do not take it personally. I ignore the emotional noise and work with the facts.

Now for one last time…

It is not a case of dividing a shape into more vertices, this has not worked - see below.

Random failures on exactly the same shape are not acceptable, especially with 8-vertex boxes!

They MUST be generated, EVERY time.

They are used in models everywhere.

Dividing the box into 2 did not work for me either, and it now has 12 vertices!

The only way it worked is by making it as I have already described, as a 2-stack 4-slice cylinder!

It has more vertices - 14!!

A thick triangle has 6 vertices. I would prefer that it should be generated, but there may not be sufficient reason.

I have not checked but I think this shape will always be convex, so maybe it can just be duplicated as a sur shape directly?

But if not or if it will be too complex, then let’s set the minimum at 8 vertices. Why not?

I don’t think anybody will have a problem if a shape is skipped deliberately when its vertex count is less than 8, but we will need a message saying cmp group xxxx skipped, less than 8 vertices so the modeller knows the sur is incomplete without losing time inspecting it carefully, and so can go directly to the shape and fix it.

Bejaymac affirms that knife-edge surs do not work correctly in-game, so in fact this could be a good thing if some are removed at generation.

We already proved beyond all disbelief that open shapes (such as mid-wing sections) unwelded shapes and unconnected shapes do not cause problems in sur builder, good sur parts are still generated.

This is great, and I would happily call this a FEATURE!

But modellers should take care to ensure that each cmp group is properly welded, especially when converting a model from another modelling program, as vertices may appear to be one but may in fact be separated into several vertices when zoomed in. Unfortunately MilkShape’s “Weld to nearest” doesn’t have a clear radius setting to fix that easily.

Do this:

Go find the .ms3d file with the Goran fighter that I posted.

The right wing tip (4 vertices) failed to generate even though it is a reflection of the left wing tip that worked.

We won’t mind that it does not generate for the knife-edge reason but the left one should not generate either. We can ignore the primary failure for now.

Select the right wing tip and Face… Subdivide 2. It now has 6 vertices.

Export and generate. It still failed when I tried it.

We can ignore this as we will skip shapes with less than 8 vertices.

Divide it again into 2.

Export and generate. It still failed to generate when I tried it. How many vertices do you see now? Unacceptable.

Delete the shape.

Make a flat pizza-box.

Export and gen (just do it to see what happens as a checkpoint, it will become clear in a minute). It worked for me.

Select it and move it to the right over the old wing tip.

Export and gen. It FAILED for me. What did we change? NOTHING except position to the right of the Origin.

Unselect the box and reselect it by vertex, do not ignore backfaces.

Put it in place of the right wing tip, pin the bottom left corner over the top-left connection vertex of the right wing by deselecting that vertex, and move the bottom-right corner over the right connection vertex on the wing. Release that and make the box roughly square again.

Export and gen. It worked for me, but it’s not the shape we want, obviously.

Select and move the top-right corner and bring it close to the top-left corner and slightly behind it in the z-Axis.

Export and gen. It failed for me. Why?

Bring the same corner up so it is in front of the top-left corner in the z-Axis.

Export and gen. It worked for me. But it’s not the shape I want. obviously.

Why should only moving one corner forward of another in the z-Axis cause a failure to generate the sur?

Bug.

When I made another square flat box and placed it on the right of the right wing tip box, the gen failed on the right wing tip box when it had succeeded above! Why?

How long has it taken to do this?

And I still don’t have a successful sur.

This is the reason I posted the file, for others to verify my findings.

I do not accept that the builder can work on one 4-vertex shape but fail on its reflection, or work first and then fail when another box is added beside that one and not be a bug.

I have no problem if shapes of 6 vertices and less are ALL skipped deliberately, but a message must be issued so the modeller is alerted.

One more excercise (sidetrack - this is the correct spelling, I hate American spelling in England and especially as this word has invaded the English dictionaries too) :-

Open the other model of many flat boxes.

Some generated ok.

Others did not.

Note the shapes - they were all the same simple flat box.

If you are still convinced, explain how this is not a bug. I will not beieve you.

So do me a favour.

Fix it so all boxes (8 vertices) will generate without failure, no matter what the distortion, we need it badly.

By all means deliberately skip any cmp shape with less than 8 vertices, and issue a message to that effect.

And add the shield bubble option using the squashed sphere.

Then we will wash your feet and dry them with our hair.

OK?

Stop denying, it pisses us off badly.

And stop continuously refuting our evidence, it takes time to make it.

Here’s a fix outline steps:

1. Detect a shape, count the vertices. If less than 8, issue a message “Group xxx not generated, less than 8 vertices.”.

2. If more than 8, do (the existing?) check routine to be sure it is convex.

3. If yes, Copy it as a sur part.

4. If no, make it convex (by disconnecting the connected low vertices and connecting the highest vertices on the 2 adjacent faces causing the concavity - this is called the “Turn Edge” function in MilkShape).

5. Repeat concavity check and fix any other concavities.

6. Save it and go to the next.

Yes, I agree, I am not a programmer but I do know the steps will be complex and I am being glib - but you guys must know how to do this. I am fine with maths, and some simple programming languages, but C, C++ etc. are unknown to me.

Here’s a fix outline steps:

….

if it can be done it will be great …

Agreed Mirkha.

I heart ST…

Can we have a confirmation that someone will try to fix sur builder and a timescale for these changes to be incorporated?

Or confirmation that it is going to someone who cares about it (and us) and will try?

If no-one then I will try but it will take me ages.

Lanced offered it to me ages ago but i refused i dont know enough to complete it
this is what i say why not make it a comunity project
maby svn it and folk can put forward there
code and fixes
so wee can make it one of the realy good tools
im sure Lance wont mind
insted of arguing why not put ower heads toghther and build it
and i also think wee should do othere projects that way

nah, working on one thing commonly is often ending up with failure. just remember your elementary school days, when you wrote short stories. if you wrote them with a mate together, even if you decided on what to write, anyway it ended up not nearly as good as if you write alone. guess it is similar with editing single files commonly especially with so much people.
also, if i remember right, Lance will mind, as the code, changed slightly can be abused badly and this is likelier the more people have their hands on it. we don’t suspect anyone but its not worth the risk, is it?

lol try abousing sur on ower server you end up in the brig
thats what the anticheats for
only fixes that benfit the program are applyed
not everyone is excepted lol

the way i look at it i built my anti cheat and it wasent just my input i maby built it but motah cannon and crazy
swaped ideas around and bits of code i put it toghere
and built it as they did with theres so it dose work
maby have a private code board for projects like these

This project does not need much work, just the changes I have suggested and for me it is finished.

With this functionality I can then make the type of surs that I need without much difficulty by doing some trickery in MilkShape - but it is not possible with the present state of Sur Builder.

If anyone wants more in it they have not said so, and I do not want to keep moving the goalpost, so I would be against more additions/changes. We need to get it finished.

Well, I took a break as advised.

Now I’m back and there’s not been any new post.

Is nobody with C knowledge able / willing to help out with this?

Is it really dead?

I am still willing to have a go but will need a lot of hints and advice to start - if LS will even consider letting me have access.

Lancer? Are you willing to help me fix it as a total C novice (hint - I used to be fairly capable at tracing old sods’ Basic and REXX and others using simple 1-letter variables and uncommented code)!!

Or do you prefer to let it die?

Well there is still my tool in development, but atm i am concentrating on university stuff. So even if this project is “dead”, I will try to finish mine.

Thank you Schmackbolzen, much appreciated as always.

I hope we can achieve both.

I’ll work on the exporter after JFLP. I should also have access to the builder (if it ever gets added to the Forge), so I may be able to fix it, too.

Thank you both, whatever you can do is very much appreciated.

It is so disheartening that each time this sur generator/exporter/builder/whatever name it is given, is taken on, the author has to restart from the beginning each time.

This particular one is so close it’s almost surreal that it should be abandoned and collapse in this way.

Good luck, I’ll give whatever help I can in testing, modelling, whatever I can manage just let me know, I’ll do my best.

So - is this thread finally dead?

Nobody volunteered to let me have access to the code or tell me where to get it.

LS you are playing blind and deaf, which is a surprise as I know you have read these posts.

And I think you have a good idea you are the cause of all of this, so I expected you to “play the white man” especially as you are only a tad younger than me.

I like closure, just tell me it’s dead and I’ll go away.

one question (or issue post?):
i have created a sur for a capital ship, divided it into root, bow, stern, pylons and “nacelles”. the sur worked fine only on the root part. on the other parts collisions with ships and missiles were not detected but only shots. also both npc’s and missiles aimed to hit the starboard nacelle (probably hardpoint HpBayDoor01) rather than the shiparch shield link or the root or HpShield01 or anything else. ofc they hit other parts if they faced them but always aimed for the starboard nacelle. why? or better: how to fix?

Take a close look at the sur by importing it back into MilkShape with the ship model, and be sure each cmp group has a sur part covering it?

If not then increase the face count of each group by dividing into more so that the sur builder has more chance to generate sur parts for every cmp group.

You must also ensure the sur part name is exactly the same as the cmp group name plus _lod1, e.g. for cmp group “Nacelles” the sur part name must be Nacelles_lod1

StarTrader wrote:
So - is this thread finally dead?

Nobody volunteered to let me have access to the code or tell me where to get it.

LS you are playing blind and deaf, which is a surprise as I know you have read these posts.

And I think you have a good idea you are the cause of all of this, so I expected you to “play the white man” especially as you are only a tad younger than me.

I like closure, just tell me it’s dead and I’ll go away.

Honestly, ST, relax. The fact that you keep on hounding this thread and criticize all of those individuals that have contributed to this tool in some form or another really isn’t helping the cause. I’d suggest you take a step back from this thread for a week or two and think about what you’re trying to do.

I realize this is a very important program for many modders but being a troll isn’t helping anything.

That’s my 2 cents.

The SUR Builder is now on the Forge at: http://forge.the-starport.net/projects/lancer/files

Project membership requires Lancer’s approval and at least one interactive orientation session. Current project members are:

Lancer Solurus
Bullwinkle
Adoxa
Schmackbolzen

There has been a lot of discussion about the SUR Builder’s ability to deal with parts that do not have a sufficient number of vertices to create a convex shape (sometimes called a “convex hull” in this thread). Let us be clear: The SUR Builder requires a sufficient number of vertices. The precise limit depends on the shape, and the limits cannot be lowered without re-writing the SUR Builder’s algorithms.

Furthermore, Freelancer itself has difficulty with shapes with an insufficient number of vertices. There is no such thing as a “correct” SUR for a CMP part that does not function correctly in-game. We have reports that some overly-simple shapes, such as knife-edges and single-points, may “slice” into other shapes, regardless of the SUR. Other shapes, such as trapezoidal prisms (boxes) that create concave shapes when positioned next to other parts, may simply be insufficient for the SUR Builder to generate a tightly-wrapped convex shape.

In other words, if you have a CMP part that the SUR Builder cannot build around, then add more vertices. Sometimes all you need to do is to split up the faces (tesselation).

The bottom line is that there is no current plan to enhance the SUR Builder’s ability to wrap tightly around shapes that do not have sufficient vertices.

The SUR Builder makes the best guesses that it can, given our current understanding of SURs, and it works quite well for most models. However, a human designer with a 3-D program can easily create shapes that the SUR Builder cannot anticipate.

If you feel that your CMP deserves a hand-crafted SUR, then make a hand-crafted SUR.

For those who find the SUR Builder useful as it is, we are glad that we have been able to make a contribution to the Freelancer community.

• Lancer Solurus and Bullwinkle