.obj -> .sur converter
-
Schmackbolzen wrote:
No, he is not using the section. I was about to recommend the opposite, like Gibbon posted to add HpMine01, HpCm01 and HpThruster01. The question still is, which HpId is needed to avoid crashes, which is the whole purpose why I added this feature for now. The goal still is to read them from a .cmp and add the corresponding simple geometry.You also should test collision for each ship with a vanilla ship (if you have not done so yet) and report back. That would make things easier to pinpoint.
These are cap ships, so they don’t have a mine, thruster, or countermeasure. I am not following on “The goal still is to read them from a .cmp and add the corresponding simple geometry.”
Here is what I have done.
I have ran/shot into them with a vannila ship. Full collision, no problems there. They move fine till they run into another ship using a sur from your builder. They vannila shoot at them fine as well. I have made more surs for fighters and have the same problem.
I’ll try and add the hpid’s to the sur builder for the fighters, but for the caps, I kinda lost on what to do.
-
The point Sushi was making is that you should only add HpMine01, HpCm01 and HpThruster01 (obviously numbering as many as required if you have more than one of those). Adding others was the cause for our lag issue at least.
-
Only final tests and some minor stuff / fixes are missing.
-
Thank you Schmack, very much appreciated.
-
Woo! That looks epic!
-
Shiny
-
Thanks all for the positive feedback!
Unfortunately there is something still not reversed in the sur format. I reversed the ref. verts. formula (such stupid as vertexcount*1.5+3) and everything, but you collide e.g. with hardpoints despite their vertex and group names. You can shoot multiparts and they break, but you still collide. So I will have to look for any non reversed difference before I can release a new version.
I attached an imported and again converted starflier .sur file. Some numbers are still of, because of some minor bugs, but they shouldn’t have anything to do with the collisions. If someone is willing to go for hex hunting and knows the format, have fun
-
Alright, I did some tests myself and I think that my tester (Skotty) expected too much from freelancer, because even with the original .sur you collide despite your wings are missing. I also did not collide with the hardpoints, no idea what happened there. I did find 2 differences though, one is a bug I fixed now (vertex count was 2 byte variable but I wrote 4, thus garbage in the file, FL doesn’t seem to mind). The other is an optimization I am not sure has a negative effect. FL does seem to double vertices if they are used in a different group whereas I only double them if the name of the group is different. I think I will have to let you guys run the tests and then decide as the results come in.
I will have to check if there is any ship with larger parts and whether they are handled differently. If not I think about not including the parts in the first part of the .sur file and only afterwards. Although the question still remains why they decided it to include it as it is right now in most of the multipart vanilla .sur files.
-
Many questions, few answers (yoda^^^)
If you looking for a ship with more parts and big parts, take a look at the Atlantis City model ( there are few on the net )
I use an atlantis city that a friend have modeled, and your tool crash if the milkshape DX tool indicte more than 10 000, if i take down the count below 9000- 10 000, your tool make a good SUR.
Don’t know if it helps you.Good luck
-
I think the most important point here is that the tool should first of all handle vanilla models and create surs for them as perfectly as possible, because many custom models are poorly made, exceed the maximum poly counts, and have non-standard naming of parts and groups.
Many large custom models have been “cobbled together” from two or more cmp files. This is not a good criteria to judge or debug the tool.
Once it operates seamlessly on large vanilla surs (there are many battleships and landscapes etc) then it can be used against custom models and if real bugs are found (not due to imperfections in the model) and can be reproduced, they might be fixed.
-
Skotty tested the RH Battleship today with another person in MP and it nearly behaved like the vanilla one. I found the last bugs responsible for this, but I will have to change the GUI since more options for the groups are needed. So there were no big errors, he just mistook a vanilla behavior for a bug of the .sur file
All in all it looks very promising. The hard work will be making it usable for the average modder, I am not sure whether this really is achievable 
-
Hope the GUI is easy to understand. Some things are still needed to be fixed though. At least you get an idea how the development progresses
-
For me it looks very good. Understandable options.
Just don’t ask about the Static and Moveable thing. It’s nearly the same but Vanilla seems to make a difference between static and animated multipart groups.
-
Looks awesome here!
-
Speaking about huge, I think I need more space
This should cover all functionality of the .sur format, now I have to make sure it actually works
As you can see I also changed the descriptions of the multipart types again, since it was incorrect.P.S.: Since the site cuts the image you have to right click on it and select view image or how your browser calls it.
