CMP to SUR Conversion Tests
-
Well the problem is, that I don’t get the purpose of the siblings (except of the root bound, that is perfectly clear). When I look at original vanilla surs, the siblings all have different centers and radiuses, which don’t seem to have anything to do with the other siblings or triangle groups. So I am asking, is this some sort of serialized tree? If so, is it pre-order, in-order, etc.?
-
The center of each sibling with a Tri (using SurDump’s output) is the center of that group. For example, looking at bw_fighter.sur.txt, you’ll see that Num 5 points to Tri 5, which is HpTorpedo01. Look at the vertices that have HpTorpedo01 and you’ll see that they match the center and scaled radii. Try looking at the log of the latest sur importer, it actually calculates each radius (I’ll add it to SurDump sometime).
-
Well I have developed my own theory and it seems I was correct. I was able to create basic vanilla like sur files. Importing vanilla surs (without hardpoints, just the meshes) and converting them again worked.
I now have extended my .obj->.sur converter to work without convex hull meshes.
I appended a demonstration for the industrial_dock.cmp of the aldebaran modular station pack II. You will see that it is 1:1 geometry and it does work in the game. The big box around it is just the shrink wrapped hull, which I don’t automatically generate yet and so I chose a simple box.If any one wants to have some .cmps tested you can give me a link or attach a file and I can try to convert them. All groups will be converted to the main root group, though.
There still is much work to be done. Sorting of the tree in the bits section is not ideal yet for example. Multiple groups are still not implemented. The list goes on
-
Well, the two cmp files I had problems with and attached here just a few posts ago are good candidates. They are solars, so it’s no problem if the sur is converted down to the root; the terrain file is huge in size and the hill has overlapping groups, both interesting in the case of a sur.
-
I have attached both surs. They seem to work pretty good, although the data structure is not yet optimal. For example, milkshape tends to clone every vertex used by a different group when exporting to .obj and I don’t filter that yet.
-
I now have extended my .obj->.sur converter to work without convex hull meshes.
I appended a demonstration for the industrial_dock.cmp of the aldebaran modular station pack II. You will see that it is 1:1 geometry and it does work in the game. The big box around it is just the shrink wrapped hull, which I don’t automatically generate yet and so I chose a simple box.Does that mean you figured out how to do vanilla-like surs?
All the geometry in one group without having to make XXX convex-hull parts and then splice them together? -
Yes, that is correct. I can convert any geometry you like to a .sur file
-
So - what is exactly the difference between your converter and the sur builder?
-
Well the .sur builder tries to build one convex hull around each mesh group, whereas my converter just converts the whole geometry without any changes. Meaning that you have to do optimizing of the geometry yourself (well it will work without, too. But then there is more calculation for collision needed). The advantage is, that you get exact fitting .sur files of any geometry you can come up with.
The easiest thing to do is just a polygon reduction so that you get a geometry which is close enough to the original, but has as few polygons as possible. Nearly all modeling tools can do that.
If you have a real complex mesh and want to simplify collision calculations you can just build your own collision mesh out of simple boxes and spheres and convert it.
-
and is it, that this mesh will be compatible with any visual geometry? cuz we heard something of “sur to model attachment” and stuff like that. although the flmodeltool made every vanilla sur compatible with any custom mesh. does it work somehow similar in this point?
-
That depends on how the .sur file is generated. You can attach certain groups in the .sur to corresponding groups/nodes in a .cmp file. The ones I create for now are all attached to the root node, which every .cmp file should have. But it is possible to change all that.
w0dk4 wrote:
Thats awesome! The real breakthrough regarding .surs IMHOKeep it up
Thanks, I will
-
Schmack: You are confusing me - not surprising, I’m easily confused…!
No offence meant, I am only keen to understand…
Do I understand correctly, that your generator makes close-fitting surs tagged Root?
The first query is - they may not work correctly in the game, since your converter will generate concave surs if the model is concave, this is what we are trying to avoid, no?
(By the way some of my bad surs worked in game under constant destruction for more than 20 minutes before crashing the game, so testing needs to be at least 30 minutes of NPCs using the sur getting destroyed by other NPCs).
Second - why are you making your own, since there is the already sur-builder almost completed? This is re-inventing the wheel?
General: - I found this info on collision solids, maybe we can learn from it?..
http://www.panda3d.org/wiki/index.php/Collision_SolidsI understand that process, but we don’t know how or what exactly FL is testing. Do we?
-
The format has been mostly reverse-engineered, but Lancer Solurus’ utility is not open sourced and he’s encountered a block and legitimately is prioritizing his game over finishing the SUR application.
Therefore the only way for Schmack to create a SUR generator is to write his own.
And yes, w0d is right; vanilla SURs are concave in many places.
-
StarTrader wrote:
Do I understand correctly, that your generator makes close-fitting surs tagged Root?
Yes they are close fitting, depending on the geometry you convert. For now everything is tagged as root, but that can be changed.
The first query is - they may not work correctly in the game, since your converter will generate concave surs if the model is concave, this is what we are trying to avoid, no?
Convex geometries are better in general for collision detection speedup. Freelancer does some silly trick to construct concave geometries, which I just also do. I tested a model with over 3000 polygons and it works without problems or notable performance reduction.
(By the way some of my bad surs worked in game under constant destruction for more than 20 minutes before crashing the game, so testing needs to be at least 30 minutes of NPCs using the sur getting destroyed by other NPCs).
Since our mod has an integrated modupdater I used the opportunity to upload the first .sur file I attached here for testing. No one has had a crash so far.
Although the tree is not created correctly yet, I had no crashes, but collision detection failures on some complex geometry depending from which direction you are nearing. This all fits perfectly in my theory. I will have a look at the .sur files the sure file generator creates to check whether it makes errors.Second - why are you making your own, since there is the already sur-builder almost completed? This is re-inventing the wheel?
Friendlyfire answered that quiet well.
General: - I found this info on collision solids, maybe we can learn from it?…
http://www.panda3d.org/wiki/index.php/Collision_SolidsHard to say, since there are many ways to solve collision equations.
I understand that process, but we don’t know how or what exactly FL is testing. Do we?
Not exactly, but since my theory seems to be correct I got a pretty good idea what it does.
-
w0dk4 wrote:
The first query is - they may not work correctly in the game, since your converter will generate concave surs if the model is concave, this is what we are trying to avoid, no?
Arent vanilla surs concave, too?
No, I’ve not seen even one. All individual sur parts that I have checked are convex.
They may look concave when they are in place next to each other but they are not individually concave.
Can you point me to one? It could be that it has a dfferent layout.
I have made great landing bay surs for big dockable ships using convex primitives for the floor, walls and ceiling, and sometimes for the forward bulkhead, all assembled together, and declared them in concave.ini and they work 100%, all the time. Single-part convex surs didn’t ever work for me.
CzW and Mirkha’s hole-in-base-station sur using the Boolean modifiers had no collision detection in certain places in it, so it is not conclusive that concave are ok…
We have been making convex sur parts for a long time, since concave ones caused crashes.
This could still be because the “Type 5” sur parts are missing.
Schmack: I am looking forward to using your generator.
The link I posted above takes us to see what shapes are used in collision detection and for what purpose, there are references to using spheres, tubes (rounded-ended cylinders), it seems only the sphere is 100% in reliable testing, and the “tube” is second. Other polygons allow slip-throughs.
But with spheres I have not tested to see if the collision is on the sphere or on the hull when the sphere is bigger than the model. Logically it would test on the sphere so it’s not useable for large ships again. We know the deformed convex “tube” or squashed sphere works very well. Boxes and others are unreliable, and this is what we are seeing with boxes and non-convex shapes - as well as the more definite crash!
Anway, back to this subject…
Great work all of you guys, and…
Schmack, we hope to have a fully-working “on-the-button” multi-cmp-group converter with optional “shield-bubble” and all Type 5 sur parts from you.
I hope this is also what you have in mind?
Take your time, no rush - 3-4 days is fine! ROFL!
Oh - one more big (bloody important) question in the light of LS’s bombshell revelation and sudden disappearance from this scene…
Will you be allowing us to have and use the generator / converter when it is finished? ?)
We don’t need the source if you don’t want to release it, just a working executable for intel PC that works on single-core cpus please!
Last idea for today…
Would it be a better idea to start a new thread instead of continuing with this one as it is for sur-builder primarily?
Thanks.
-
