.obj -> .sur converter
-
It seems that some of you think I am alone in wanting the options of shield bubble (for fighters), no shield bubbles but shrink-wrap (weapons, single sur part exports, bases, and large ships for FL compatibility), and close-fitting surs with no shrink-wrap at all (large ships with gaps, bases and large dockable ships). Fine. Then you will never need them, right?
well, you’re not alone but, personnaly, i don’t have an ounce of competence in this area
so my dream is to take a cmp –-> with a tool make a sur directly from the cmp and of course have all covered like weapons …ect …but but but i no longer believe in Santa Claus
and i imagine a good tool requires time
on my mind it’s a first version, let’s see what it becomes -
i doubt the people from microsoft or digital anvil ever had a cmp to sur generator. they rather did model all of their 50-60 surs manually and exported them with a converter. ofc not with a version similar to what schmackbolzen uploaded into this topic. maybe one of their first converters was like that and maybe one of the ones schmack will release in recent future is just what they had in the end. we can be happy that there are programmers doing progress with this format. the perfect tool is coming soon.
-
Well if anyone wants to write the documentation for me I am more than happy
I already asked natives speakers if splicing is the correct word and they said it is (you could also say split). I also think the problem here is that I don’t know what knowledge is missing from my readers. And of course that this is a topic which is not covered with common English so I am having trouble finding the right words.
If you want to try to explain correctly what the tool does you should at least have some knowledge about common collision meshes and the convex stuff. I assumed that people who used this tool in the beta stage would have at least some basic knowledge about how the .sur format is interpreted.
The goal is of course generating a vanilla like .sur file, but I first want to get the main part working, which is vanilla like collision geometry (which I nearly achieved, only the tree generation is not quite the same as I did not exactly find the criteria yet). Later multipart meshes, real hardpoint geometry, shield bubbles will follow. But for now it is important that basic collision works.
Btw. the converter does already more as any previous sur tool did, since it automatically generates the convex hull for each connected triangles it finds or if it differs to much splits them so that the geometry is preserved. Basically it guarantees that every geometry you input will collide correctly (except in some case where the generated tree is still wrong).
If you want to know more about the trees look up binary tree and bsp tree (from which Freelancer seems to use a variation).
-
@ST: Pardon me? I’ve already done enough grunt work to know how it is. I don’t need no lessons from you, as much as I respect you as a modder. Feel free to defend your point, but personal attacks are unnecessary.
Now. Reading your post, it would appear everybody’s fine with broken tools and halfway done SURs. I re-read the entire topic and I cannot surmise what made you say that. Throughout, people are congratulating Schmack on making the tool and that’s about it really.
And here’s the party crasher: it’s almost certain all the vanilla SURs were built by hand. If you’re looking for a tool that’ll reproduce them perfectly, tough luck. Computers have a hard time doing models and I don’t expect they’d have any easier time making SURs for those models. If you want an automated solution, LS’s tool is as good as it gets. If you want truly optimized SURs, then you’ll need to do them by hand, just like how the devs did.
Schmack’s tool is fantastic in that as long as your geometry works, you’re guaranteed to have a working SUR. No fiddling with fucking MS3D trying to understand why it unwelded 34212 vertices and messed up your import. Just export to OBJ from your favorite graphics program and bingo!
Furthermore, it wouldn’t be a stretch to imagine a simple change to support drag and drop. Schmack, I think it’d be nice if you could add support for a configuration file that stores all the options the GUI offers and thus allows people to just drag and drop the OBJ file onto your EXE to produce a SUR file. The process is equivalent to using a command-line tool and typing the name of the OBJ file as the first argument, so it’s simple and it’d streamline the process even further. It then becomes a matter of export, drag, done.
Finally, ST, you set the guidelines and specifications, right? I don’t recall them being approved and you hiring Schmack or any such thing. You told what you wished to see, nothing more. You’re free to be a sad panda if you so desire, but don’t come in like that and say it doesn’t meet the “guidelines”.
-
Thanks for the further explanation, FriendlyFire.
Concerning your suggestion: I have tested it and it is indeed rather simple to support drag and drop. I write in in the file path input field for now. A config file is also easy to make, I can include it in one of the next versions.
-
this is turning out to be a really good tool.
i tested this out on two models. the first one was a normal poly model (1200 verts, about 2300 poly’s) sur file was generated and turned out rather good looking too.
the second model was higher poly model, about 11,000 verts, and about 9000 poly’s. it took a while but it did generate it. i had to redo it because i forgot to remove the hp poly’s. so i removed them and attempted to redo the sur generation, however this is where problems started. from this point forward the application throws a out of memory error 9 out of 10 times while the other 1 out of ten times it simple hangs on the generating tree … method. and it now does not matter the poly or vertex count, it just simply stopped working.
also you may want to consider multi threading the application. specially the routines that are the heart of the app.
cheers though mate, good job so far.
-
I’d argue that you shouldn’t be using a 10k+ polygon model for a SUR file. It should be like a fifth to a tenth of whatever normal model you’re using. At that point, multithreading would have little use because the generation would already be fast enough whatever the case.
I’d much rather see bugs fixed and features implemented
-
Downloaded the sur converter, opened MS3D, imported a ship cmp, exported as .OBJ. Was kinda confused when I fired up the converter but common sense always prevails. Left the 1st block at 5. Checked the 2nd and 3rd. Typed in the HP’s for the ship, hit go.
The sur it spit out looked beautiful, but kinda large, about 140KB….
So I fired up the dev server, launched FL, undocked. To my delight, no crash!! No server errors, no spew errors. Fired up 2nd pc and began shooting the hell out of it. Registers gun hits, missles and torps, flawlessly. Unmounted my shield and bumped it about 100 times, still going. I have seen the same behavior with single group surs I made using sur builder. They worked great just shooting at them, but under stress test about 18 out of 20 I made using it crashed between 10 mins to an hour.
I shut down the server, set zone to spawn 30 npcs and let it run. 2 factions both flying the same ship with the new sur, and a base shooting at them both. 2 hours now, no crash.
All I can say is EXCELLENT WORK!!!
The only problem I saw was the memory leak. Oh and since my girl has been out of town all week, she will want to kill you when she gets home today as its now 6:30am and I been up all night playing with sur files…
-
Thanks! It’s nice to read that you guys are satisfied Spend enough time testing to make sure everything is working ^^
As for the memory leak: Yes it is annoying. Either I did not notice it because I used rather small models for the testing most of the time and it was always there or it slipped in in the last days. Gonna have to look into that and fix it before anything else…
There will be some performance speedups after that, I optimized first the general algorithms but there are still some tweaks left because I wanted the functionality first. The slowest part seems to be finding connected triangles, that’s why it takes so long on larger models.
-
Beta 1.1 is available now. See first post.
-
Found two more bugs, v 1.2 is now available. I am testing large models now, maybe more to come ^^. See first post for details etc.
-
I think I found all the bugs in tree generation now. Also did some speedup. BETA v. 1.3 is now attached in the first post. If there are still problem e.g. where you can fly trough geometry please post here.
-
schmackbolzen, can you extend your sur program with the option to make sur for 3db-s also (the 3db sur don
t 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. -
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.
-
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.