.obj -> .sur converter
-
Ya, I was able to do something similar with a ship in FW:ToW. My only concern was the shield bubble. Is there any way to remove that or make it form fitting?
Otherwise, it’s a fabulous tool!
-
cata123 wrote:
schmackbolzen, can you extend your sur program with the option to make sur for 3db-s also (the 3db sur dont have root group , its replaced with 00000000 instead of 2D8F6812).
It could be a box checked for example .
Those types of sur are used in all space scenery objects (asteroids) and it`s annoying to replace every time with the hex editor.Yes its already included but not in the GUI since the last time I tested the .sur file did not work at all. Gonna have to look into that, because a lot has changed since then.
Sushi wrote:
My only concern was the shield bubble. Is there any way to remove that or make it form fitting?Shield bubble? There is no such thing. Are you talking about my converter?
Concerning the rest: It’s nice to read that it seems to be working for now. I will try to fix the last errors in the next days and call it version 1.0 without beta, so that I can start the next version someday soon (assuming no further bugs being found)…
-
Really? Then what’s the shape surrounding ST’s model? I see the form fitting sur but there’s a larger all encompassing part of the .sur.
-
w0dk4 wrote:
Schmackbolzen wrote:
If you view the converted geometry there is always a convex hull around everything! This is needed for collision detection and you will not collide with it!
OH! I didn’t get that. Good to know
-
This is what we called the “Shrink wrap” - Sur explorter does this, and it is present in the vanilla surs for warships. Only fighters have the shield bubble.
When we export the sur parts to use with sur splicer, there is no “shrink wrap” around the ship at all.
I don’t know if this “no shrink wrap” is needed for anything? Bases or scenery for example?
-
StarTrader wrote:
This is what we called the “Shrink wrap” - Sur explorter does this, and it is present in the vanilla surs for warships. Only fighters have the shield bubble.When we export the sur parts to use with sur splicer, there is no “shrink wrap” around the ship at all.
I don’t know if this “no shrink wrap” is needed for anything? Bases or scenery for example?
Apparently it’s quite important in first level collision detection, from what w0dk4 was telling me.
Anywho, this program is incredible
-
The surs we have been making until now are only faulty because they have had no hpids. Otherwise they work well without the shrink-wrap.
This is one “why?” that I have not yet understood.
When we use Sur Splicer to make surs, there is no shield bubble and no shrink wrap either, yet those surs work well for collisions and hits too.
So - should we always have a shrink wrap on large models, or are there vanilla models of anything (bases, scenery, other?) that must be made with no shrink wrap?
-
Furthermore, what’s the point of the shield bubble? Shield hit detection relies on another SUR, doesn’t it? So then why do fighters have them at all?
Also, does/will the converter do shield bubbles?
One thing to note, and something that bothers me; when loading a SUR made by the converter into HardCMP editor, the editor crashes. That’s kinda annoying, and the editor doesn’t crash when loading SURs made from MilkShape’s SUR Exporter.
-
-
mknote wrote:
Furthermore, what’s the point of the shield bubble? Shield hit detection relies on another SUR, doesn’t it? So then why do fighters have them at all?Also, does/will the converter do shield bubbles?
Shield bubbles are just for your eye, details. If your shield is online the hit detection will use this shield bubble. No hit will reach your ship, it will hit the bubble far around the ship.
But you don’t realy need this, like I sad: just a detail.The sur converter won’t create shield bubbles. And one point for you: shield bubbles are using extra surfiles (they are defined in select_equip). These bubbles are represented by a 3db file without visible geometrie and just a HpConnect Point.
-
The reason why .sur files generated with the sur splicer don’t have convex hulls around everything is, that it uses the trick to put every group as complete new part into the .sur file, meaning that you have for every part a new header, a new group, a new triangle list and a new bit section. This is what basically is used for multipart meshes (although the multipart groups also seem to be included in the very first part of the files, didn’t have the time to look into that yet).
It seems that until now no one besides me figured out how the bit section really works, so they just used one entry instead of multiple (a side effect of the tree is that if you only have one node it also is the convex hull around everything). As soon as you have more than one node you need this hull to tell Freelancer where the geometry starts and where it ends.
If i would use the method the sur splicer uses the file size would be way larger as it is already now if you have many groups. Plus it was never meant to be used that way.
-
It would be logical for the shrinkwrap to be used as a “second-level collision hitbox”. That is to say, the game would check for hit detection in three increasingly costly steps:
- Bounding boxes/spheres; very quick and efficient.
- Shrinkwrap, simplified and convex polygonal model.
- Full SUR, concave and complex.
It’d only reach (3) if both (1) and (2) register a hit. Without a shrinkwrap, it has to go straight from (1) to (3), which can be costly if the SUR has lots of small bumps and details or openings. I’m guessing it might even use different algorithms (read: faster for the former) for shrinkwrap and full SUR, since the former can be assumed to be convex.
Thus, shrinkwrap is not essential, but helps with performance. I think Sushi’s current tests have been conclusive on that matter.
-
Skotty. wrote:
The sur converter won’t create shield bubbles. And one point for you: shield bubbles are using extra surfiles (they are defined in select_equip). These bubbles are represented by a 3db file without visible geometrie and just a HpConnect Point.if you delete this file, freelancer takes the cmp’s hitbox to “replace” the shield’s hitbox
-
The .3db shield model has a sur, this is the shield bubble visual collision/hit box, and it can be resized. I’ve done that to make a very large dreadnought shield. But as there is no shield bubble around my large ships, collision detection is not triggered until the munition hits the ship, so hits only appear at the hull surface.
HardCMP does not crash for me, I am using v1.8 (v1.23 does not work with my graphics card). My surs open fine including the large Avioki.
The reason for bounding boxes is to avoid the game engine having to continually check for hits. It only needs to check for hits when any bounding box has been penetrated by another object, so it conserves processing power until it is needed.
The shield bubble actually uses the shield shape defined in the shield_link = line in shiparch.ini to show the visual hit.
There is no overall shrink-wrap (bounding box) around the ship if the ship has a shield bubble, because the shield bubble has a bounding box. When there is no shield bubble, each group has a convex sur shape as normal, and there is a bounding box (shrink wrap) around each group too. These are the “type 5” parts in the vanilla sur files. Open one in MilkShape with the Sur Importer and take a look by peeling off the layers and then you can see clearly the additional bounding boxes. These are the ones we could not reproduce.
If you remember (and as you can see when you import a sur) there are two identical shapes in the sur for the shield bubble - one is bound to HpMount (0xF00FB9DE) and the other is an identical “bounding box” which surrounds it, and has a 3 or 4-digit hex number (an offset, but from what I don’t know) as its id.
I understand that the collision engine checks for penetration of the bounding box to start checking for hits, and as the shield bubble (HpMount) is identical in shape and size, it registers a collision or hit immediately.
So if we want to see the visual shield around the ship being hit, we need to have the shield bubble, or else the visual hit will be close to the ship surface.
This is fine.
For the shrink-wrap around an entire ship, this is the bounding box, and checking for hits begins when another object penetrates this bounding box. The engine checks for a collision between whatever object has penetrated this bounding box and any collision boxes inside this bounding box. The collision boxes are the sur shapes around our ship parts or object parts. If there is no collision with any collision box then the penetrating object is allowed to continue on its path.
So if there is a hit then it appears close to the ship’s surface, where the collision box surface is found.
This is also fine.
So overall and for compatibility with vanilla FL surs, I think we do need a shield bubble option for small ships.
Now how about when there is no bounding box at all, only sur shapes, as we have when we generate a sur with Sur Splicer?
Is this last version used in vanilla FL, or is it only a fluke that we made with Sur Splicer accidentally, and it just happens to work as long as we can put in the hpids?
Since the shrink-wrap is only visible in HardCMP and when we import a sur into MilkShape, and does not cause collisions, but only triggers collision detection, do we need to remove it at all?
Lastly - the bounding boxes (type 5) that are in all vanilla surs around the model groups - what exactly are they there to do, since collision detection is already triggered by the shrink wrap or HpMount bounding box around the entire ship?
-
@ST: Please don’t mix up things:
- The type 5 part is the convex hull around everything (which you call shrink wrapped)
- It even is there if a shield bubble is included, but it is the same as the shield bubble, since it is the largest part around the ship (convex hull…)
As for the sur splicer: See my last post (maybe you missed it?)
@FF: Also don’t forget the bsp tree, which usually does a major speedup in collision detection. None of the custom generated .sur files had one so far.
Concerning HardCMP: I have one .sur file it doesn’t like, but it’s rather large. Gonna have to look into that some time.
-
Yes there’s been a flurry of posts, I’ll read them and check and fix my posts.
-
Schmackbolzen wrote:
@FF: Also don’t forget the bsp tree, which usually does a major speedup in collision detection. None of the custom generated .sur files had one so far…Huh, I’d missed that. Guess it further explains the incredible performance boost we’re getting with those new SURs then.
Mad props to you, Schmack
-
ok i done some tests tonight
i don’t know if it can be usefull for you but …test on the a9, multipart cmp —> it works like a charm
test on the colony3station (who is pretty big and complex … colony3 station) –-> no way, with several cmp, no differences, no hit registred and no hull detection
test on the avatar station, it seems to work
i noticed one strange thing, maybe it can be important for you to knowat avatar1.jpg, i can pass through
then at avatar2.jpg, i shoot on the base
and at avatar3.jpg, i can’t pass anymore
it’s the same place, exactly
i don’t know what the laser has done but can he “activate” the detection ? -
@FF: Thanks ^^
@Mirkha: Don’t forget that it is attached to root only. I would say that’s why it did not work at all.
Concerning the flying through: I would have to test it myself with the model to be able to draw any conclusions.
