CMP to SUR Conversion Tests

1st TY 4 that great tool m8.
2nd 1 or 2 suggestions:

An option to get a more ‘dense’
and possibly ‘closer wrapped’ SUR.

Example #1:
If i have a very simple shape - say a ‘Borg Cube’ -,
it gets me ‘only’ a very ‘simple’ SUR
with a very few lines shown in the animation screen.
My impression is, we get collision detection only,
if the SUR has enough edges or ‘lines’ as shown in the animation.
Now if that model is big enough, it seems, a small ship
can sometimes slide through between those few ‘lines’.

Example #2:
If i have a more complex, big structure with interior

• say something like ‘Deep Space 9’ -,
  it gets me a more or less ‘only’ a sphere from the outer part.
  Would be cool to have the collision detection
  with things like the arms on one hand and also
  the inner structure on the other.

thx Gibbon

a little feedback

i done 262 ships for the freeworlds french mod and … all works
so -___- it’s really really impressive

but i have a question

i place the ships as a base to test the hits and hull collision
all is working, but the hits are no longer visible at all, at maybe … 10/15 meters
so for a capship you don’t see the hits anymore.
it works because i added hit_pts to the cmp on the solararch.ini and i can see the life who come down

so normal ? it’s due to the new hitbox ? or it’s something else ?

Hi LS, thanks for the explanation…

My replies to your queries…

3. Yes the shield_link is always needed in the shiparch.ini file, but as you know standard FL fighters always have that darned double shield-bubble (the HpMount 0xF00FB9DE and its twin with an offset value instead of mesh name crc) in the sur as well. I don’t know why, but it is compensated by FL if it does not exist in the sur, and the hits are shown flashing on the shield-link shield bubble until the shields are down just like if the shield bubble did exist in the sur.

6. Again I don’t know, although Bejaymac has tried to explain so many times that one is for collision detection and one is for weapon hits damage. One uses the mesh name crc and its twin uses an offset value like 0000270. These ones with an offset value instead of a mesh name crc are placed at the origin by the MilkShape sur importer instead of over the cmp part as they should be - HardCMP does, maybe it’s because the sur importer is not interpreting the offset values correctly if at all for these? So maybe by looking deeper into the HardCMP code you or adoxa would be able to understand the offfsets that are used and we (well… not me!) can then fix the sur importer too?

On duplicate surs for every non-root part… Well - not all cmp parts (other than the root) have the double surs. Only the wings, engine hardpoints, equipment hardpoints and weapon hardpoints do have them, and in case of weapons they only have them if they are mounted on the wings, and this becomes that convex sur covering both the wing and the weapon sur. You can see this complex sur even in HardCMP but it’s hard to distinguish, the best way is to import a sur into Milkshape and then you will see the double surs are all at the origin, just move them out one by one to see the shape they cover. The weapon surs are all extended tapered cubes, and the wing+weapon surs cover this extended tapered cube plus the wing it is sitting on.

Non-root hull parts and pylons (e.g. as in the stiletto and sabre) do not have double surs. So making double surs for everything except the root may cause problems.

And on only the root sur part needing to be convex… Well if we can determine that indeed only the root sur needs to be convex then it would be a terrific relief, as all non-root surs can be concave and be bent, and follow hull and body contours, as in my suggestion of a standard-shape-tradelane sur that can be then made of only 5 parts - a convex root sur part for the middle and four long, bent, tapered horn sur parts meeting at the top and bottom of the rings - easily and quickly made from copying each of the ring cmp quarters. However in standard FL ship surs, these sur parts are all indeed convex.

So it is worth spending a couple of hours proving this out, as it may save you lots of time.

Thanks as always pal.

you sure ?
i noticed that if you make a concave part, the hits are not observable on this part
and it generate a push effect when two sur enter in contact

I’m able to observe hits on the concave parts on at least one of my SUR files, so it at least works sometimes.

MK

on the bases i’ve made, the hit works (because i can see the life of the base come down) but the hit is not seen
on all concave part

Ok, so it works but does not show the hit flame?

Well in some cases I can live with that, e.g. on very large ships.

So in this case we can make close-fitting non-convex (i.e. concave!!) sur parts as long as the root sur part is convex?

Super - if this is really confirmed then LS needs only to ensure the root part is convex, or even just make a sphere that fits inside the ship centre and call it root, and all other parts can follow the shape of each of the ship part groups?

Then…

If this is so…

then…

wow!!

… get cracking, LS!

Don’t worry about creating the gaps between booms and stuff in ships, mine will always be separated into groups that will prevent gaps being filled with sur parts, I just need a sur part for each ship group. And the double sur parts for hardpoints and wings as in my checklist above.

As long as others do the same there should be no problem with multi-part models.

That’s amazing, but what do you mean by “properly defining your ship into pieces”?

Holy shit, that’s amazing. As for the 18 part groups, couldn’t that be beaten using the method that FW:ToW developed?

http://zomgbayz2.googlecode.com/files/Infinite hitbox parts tutorial.wmv

And the program can handle multiple VMeshes?

I don’t think what Sushi’s asking will be possible with this though, as that’s creating new dummy mesh objects (which have no real geometric relation to the functional model), but linking them to previously generated Sur parts, which are positionally correct and offset to match the original model’s geometry.

But… if you broke the model up to match the Surs, into multiple vmeshes: base_left_wing01, base_right_wing01, base_cabin, base_power, etc… and the program supports this, then there’s no need for dummy meshes anyways (which will be better anyhow if the model ever needs to be animated) .

So that means making a complex model from say 5 Milkshape scenes, each exported to their own CMP, then merged by hand. That should support auto-generating a Sur, as long as the program handles multi VMeshes.

LS -
OK, never mnd anyone else, I like what I see, so gimme gimme gimme!!

Sushi-
The method used to get round the 18 group limit will not work with this, because it combines many or all of the original ship parts into one group.

By this method, the ship will not break up into those separate groups when it is destroyed either. But this is not important for large ships because most are set to just disappear instead of “shatter”.

Everyone-
The key is to separate your model into sensible component groups, up to 18. This has been enough for almost all of my models.

And by doing it this way you should have enough real ship groups to ensure that you do not need to make any dummy parts, which I hate and detest!

So by separating ship booms and wings etcetera into one per group, LS’s sur generator will wrap each one in its own sur, and will leave the spaces between them empty, as they should be.

And when the ship is destroyed, those booms will break away and spiral off! Nice!

Sushi-
The method used to get round the 18 group limit will not work with this, because it combines many or all of the original ship parts into one group.

umm… no?

Sushi-
The method used to get round the 18 group limit will not work with this, because it combines many or all of the original ship parts into one group.

Ya, it definitely does not do that. That’s why we use this method to hitbox our 7 piece vmeshdata spliced ISD. I think it would work

Amazing LS, simply amazing.

This work will make everyones life so much easier with modding. I cannot wait to see what else you can do with this (or is there anything else??)

Sushi, W0dk4 -
Sorry, must have confused that mehtod with the other “zomgbay thing” that grouped all ship groups into the 1st group and used dummy groups!

I’ll download it and have a look at yours now.

LS -
I notice that the saucer is shown in dull white whereas the other parts of the NX-01 are bright white. HardCMP also showed “good” sur parts in bright white, and “suspect” and non-working sur parts in dull white, can you how did it do that?