.obj -> .sur converter

It is this type of misinformation that drives me bananas.

Mknote - get some glasses on your face and look again.

The bottom wing is made in 3 parts, the vertical pylon and the port and starboard wings.

There are absolutely NO concave Sur parts in any vanilla ship Sur!

Check for yourselves:-

Startrader, you may be right, but please keep it civil!

Thanks.

Schmackbolzen wrote:
@Startrader: I am not sure what offsets you are talking about. Each triangle group has a type offset, for which we know that number 4 means it is geometry you can collide with and that number 5 means that it is the convex hull around everything. Also there is one offset for the hash of name of the group in the .cmp file, which I set to the hash of “root” for now. That’s all I know and I did not look into multipart .sur files yet! So I can’t tell you much more for now.

I mean this:

"Type 5 surs:
I don’t remember when or why we started calling them “Type 5” surs. These are the ones that somebody said have an offset, and not the CRC of their name, as their id.

But this does not make sense…

For example in the Stiletto (my favourite standard model), there are several of these (import the sur into MilkShape with the original Sur Importer):
M23 - 000018d0 - shield bubble bounding box
M28 - 00000270 - upper port wing + weapon bounding box - why are these the same?
M31 - 00000270 - lower port wing + weapon bounding box - why are these the same?
M34 - 00000290 - upper starboard wing + weapon bounding box - why is this different?
M37 - 00000270 - lower starboard wing + weapon bounding box - why are these the same?

If it was an offset to a mesh, there would have to be 4 different offset values, because none of these are identical.

So, can you tell me if this is really an offset, and if so why we have 3 values the same and 1 different?

Also note that the engines and wings and weapons all have bounding boxes as well as sur parts in the sur, but all of those are translated correctly to the name, because their CRC is the same as their parent group.

I would have expected to see “offset” values for these like the ones above, and not CRCs. Any explanation to help clarify?

And what I am leading up to is, what function do they perform, and can we replicate them in a sur?"

w0dk4 wrote:
Startrader, you may be right, but please keep it civil!

Thanks.

Edited.

Okay, perhaps it isn’t present in Vanilla SURs, but that doesn’t change the fact that it does work. Here’s a wing from my Hellhound SUR:

You can see the obvious concavity, but the SUR detects hits just fine nevertheless.

OK, got that. Sure there are no problems in hit detection and collisions detection on it?

As I said I’ve not made any concave sur parts deliberately and I’ve not tested any.

@mknote

what you show in that screen shot is not a true concave mesh. It is several convex meshes grouped together which does produce a valid collision mesh.

here is a couple examples of what i mean.

this mesh is a simple example of what you are showing. it is convex. Because, notice that it has several convex meshes grouped together. Yes they intersect, but each mesh is self contained and closed.

this next one is concave. because the two ‘pylons’ and the wing are a single mesh. the pylons are part of the wing now, which creates an invalid collision mesh.

In newer engines this is not a big deal, because newer engines are opting for using the actual model itself for collision detection and not a seperate collision mesh. But FL does not do that.

Interesting. I hadn’t considered that possibility. I assume that you’ve tested this and are not just assuming, correct?

Nevertheless, the SUR I have works fine for what I’ve tested; I haven’t put it through the ringer StarTrader does, as I don’t test in multiplayer, but it appears to detect hits as well as vanilla SUR files, and is nicely form-fitting.

i am not just assuming no, i am a game developer myself.

You can get a ‘concave’ feel very easily. lets take a standard Arch (like a roman arch) now this type of object if you try to use it as collision mesh will probably not work as it would turn out to be concave and either detect no collision in game or crash the game.

now if you take that arch and use several convex objects that are positioned and oriented correctly you get a really good collision mesh that will work, not crash the engine and allow players to flow through the arch opening.

you can group all those convex object into one so long as each individual object that makes up that collision mesh is properly convex.

This. This here tool? This will make the 4.86 hitboxing for Discovery a LOT easier. As one of the guys who primarily does this, I’ve found that this works infinitely more easy then sursplicing. There is just one feature missing:

Is it possible to include a feature to match certain pieces of a hitbox to a specific component name in the CMP? When using the SUR splicer I was previously using, this was possible. This is neccesary in order to support SUR components tied to animated parts, such as docking bay doors.

I’ve been yanking a few of our static models though this tool and so far, no problems. I -strongly- recommend anyone using this tool to create convex shapes around your ship and removing the original parts before exporting the shape to an OBJ for this tool. Especially if you use this for improving server performance. Reason being that you get a bloated SUR filesize, which I imagine is also more complex.

Aeternus - don’t you know it’s just being developed as we write? All will be revealed when it is completed.

Sweet. Let me know if you need someone to test that functionality - still got quite a bit of work to do on the SUR side. But for now the 228 preexisting models that need to be converted over will keep me busy for a while…

Another thing you may wish to include is an option to generate a shield bubble (using perhaps, a preset distance from model X, Y and Z radius, offset by the model center?). I unfortunately have no idea how you tag a group as shield.

For the shield bubble, the easiest way would just be to create an ellipsoid using the bounding box’s size. No need for user input other than a checkbox toggling between shrinkwrap and shield bubble.

Good luck with the conversions Aeternus.

It’s just taken me 6 hours to regroup a model to make a new sur for it, still not finished. Then I still have to break it into different chunks so the surs for the docking hangars will work.

Shield bubble - Yep a check box is fine for me, although others might want a “thickness” value (i.e. gap from the model surface at the extremities to the bubble) that they can set? It could be better for larger ships.

1 metre steps should be fine. The X, Y and Z bounds plus 1 metre in each direction for each axis (i.e. 2 metres diametrically) is good for most ships including medium sized? I don’t use one for huge warships but may be useful in future if someone cracks how to have collapsible dockable ship and base shields etc…

But let’s get multi-group / muliti-part surs working first.

Just wanted to say that we’ve nearly converted all of the FW:ToW using this tool and have noticed a difference in performance. Thanks again for working on this awesome tool, Schmack!! It’s revolutionary!

Cool, o encounter some errors when making SURs for one or two models, some “divide by zero” errors, when i put the HP names, and if i dont use the HPName functions, the soft just freeze. But i think the problem can come from the model itself, need to do more test, but good job for the tool

i have “disassembled” Port Franc 1 (large station) in some pieces of station, to make a “wreck” and use your software with hardpoints checkbox uncheck. The Sur seems to be good in HARDCMPViewer, InGame, Hit detection is OK, and collision detection work 3 or 4 secondes, then FL freeze when i try to pass in he "wreck, without make any collision.

I can upload the model if you want.

Here is a screenshot of the CMP to understand what i mean :

and a screenshot with the generated SUR:

Uploaded with ImageShack.us

Schmackbolzen wrote:
@Sushi: Did you encounter no bugs in collision etc? I have Mirkhas model here which does not work correctly. But it’s the only one so far. At least I have a proper testcase ^^

@Ezekiel: This sounds like the one known issue. Should be fixed in the next version which I should be able to finish in the next days.

Nope, haven’t had a problem with any collisions even with some of our bigger models