.obj -> .sur converter
-
I’ve a problem with you tool, I open a cmp to obj model, I say 15 use convex hull,… I click go and the tool says invalid file name.
vulkorasdesolator.obj is the file name, what can I do. -
Wow! You think I’m so idiot… ( No of cours, I’m kiding) I export at wavefront obj exporter, so it can’t be aan error from me, I will test somthing els to solve that.
-
StarTrader wrote:
Schmackbolzen:Very good results so far. Here’s my Avioki capital ship in space dock, with a new sur I can fly through all the gaps including the rear boom “nugget”, and collide with all body parts as it should. I was unable to fly through any body surface.
Good work, thanks.
Looking forward to the next step.
can you detail how your cmp is done please ?
multipart ? exported with the 0.21 or 0.3 exporter ? -
It works, just an error of manipulation.
-
Freestalker means it was “Finger Trouble” - we all get it.
Hi Mirkha. It’s multi-part, 23 groups. I’ve attached it for you and anyone else who wants to see it, with its new sur and the .mat file.
The “nugget” ( actually I should call it “doughnut” ) is made in 4 parts - top, bottom and 2 sides. I could have made it in 6 or 8 parts to be more form-fitting, but it’s good enough.
-
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 , it
s 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.