.obj -> .sur converter
-
Ok, sort of get that. An example of issues i’ve had with .obj format is they won’t work for me in MS. I have to load an obj format model into 3dsmax, convert it to 3ds, import that into MS for things to work. Pain in the arse and unique to me i think but even so it’s an awkward workaround.
So from what you’re saying i would have to have a sur to start with? But that’s in sur format so what does obj have to do with anything apart from being a modelling format?
I’m sitting here with this tool and absolutely no idea how to use it. The options are totally confusing to a novice, for example.
From the program,
Option 1 - If maximum distance of connected triangles (spelt wrongly in utility) to convex hull is smaller than (insert number), use convex hull, else splice connected vertices
This means what to somebody picking this up for the first time? How would i know what number to enter?
Option 2 - If difference of connected triangles to convex hull is too great, use convex hull instead of splicing
Meaning?
Option 3 - Append hardpoints to HPid section (one name per line)
An example for those that know nothing about this would be nice.
I’m not knocking this program as i’m sure it does what it’s supposed to but as a new user i’m still trying to workout exactly it’s purpose. It assumes the user knows all the above points but that’s not the case i can assure you. Most people want simply to click on a cmp file, press generate sur and get back to a bit of coding. After looking at this program i still don’t know from the available options what it’s actually supposed to do.
Also does this mean i’d have to convert every model i have to obj format? That isn’t going to happen anytime soon. We all use cmp format, we need a cmp to sur builder, It really is that simple.
-
Hi Schmackbolzen: Thanks for your great work, appreciated.
But I’m afraid I agree with Gibbon - converting many models to .obj is not something I am prepared to do.
This method was not expected, and we didn’t have a chance to tell you this before you put in so much effort.
1. Think of the other utilities that need extra steps, they aren’t used as often as they should be, nor by so many modders. It will be a shame to continue with this project when it will not be used.
2. As you say “this is not what is in the vanilla files”, we have incompatibility - and I lose interest. I don’t want another “nearly OK” tool.
If you need to automatically convert from internal MilkShape memory (model loaded) through .obj and then to .sur as an “internal” step without having the modeller do it, then that is OK.
But I (we all) want a fully compatible, one-step tool, with the selectable options I listed earlier. I have defined the specification pretty well for everyone over the last year.
Hardpoints must be read from the MilkShape memory, modellers should not be expected to re-write them into the exporter/converter by hand.
Thanks if you decide to understand this and make it the way we want it.
For me the ONLY criteria is that the generated sur file for any standard vanilla FL ship, say for example the Stiletto (bw_fighter), MUST be exactly the same as the original vanilla sur file, with all the same components. And it has to work, of course.
If you decide not to, then I am sorry, and thank you for trying, but I won’t use it very much (if at all), because I can already do this with existing MS tools and 3DSMax tools, and it is a pain now. Your utility will not make anything easier if you make it in the way you say.
So many people criticised me for such a long time, and some even insulted me by accusing me of deliberately making bad surs for all this time, until I finally isolated and proved with help from adoxa that it was indeed caused by missing parts, just like Bejaymac used to tell us time and time again.
And so all the surs we have made with these current sub-standard methods and tools are bad.
So the criteria can only be a complete sur identical to the original for vanilla ships.
Once we have this, surs for custom ships will automatically be in the same standard format too.
Thanks for understanding my point of view.
-
w0dk4 wrote:
Actually, I think I should also stop developing the 3ds max exporter and make it a standalone .obj -> .cmp converter (would also get rid of the 3ds max versions compatability problems).
W0dk4 old friend - I was so excited about your exporter until you wrote this. If you do then I will lose interest in your cmp exporter for the same reasons as above.
obj is a simple format, basically lists of vertices in plain text format. So yes it is easy but is also limited.
-
i’d prefer obj converters. you can export those files from any program, no losses at all (wavefront might be limited, max is not, just export obj and mat and youre ready to go). moreover, it makes us independant from the limits of ms3d and from the issues we know from the sur exporters and cmp exporter. no matter what program we use now, we can just save everything up as obj and can convert those to mesh libraries and surs as we wish, faster, better. export to obj is no step too much, you can do it with the modeler program you use.
your quote, Schmackbolzen, seems to tell us, that your converter does surs in the same way vanilla surs are done, too. though this is yet WIP it is already more than we ever had and probably became exactly what we have been waiting for. thank you.
only thing is indeed, what gibbon said, a documentation on options would be helpful.
-
Gisteron:
Which part of this did you not understand?
“- The tree of the bit section still is not the same as in vanilla files. That means depending on the geometry you can fly through if you try hard enough.”
What are you going to do when my ships do fly through it, accuse me of trying too hard to break the tool?
And “You can help the tool if you put every convex geometry in a single group.” defeats the objective entirely.
I will repeat once more: “the criteria for this tool is the creation of a sur for a vanilla FL ship that is identical to the original sur”.
Nothing less will do because the new surs will then not be compatible. All components of the vanilla sur must be present.
You are undermining the construction of what will be a good tool.
If you are happy with this as it is, and think you are already creating good surs, then you already have the tools you need, so be happy, take a back and quiet seat, and let us get the tool we need.
We do not yet have the tool we need.
-
w0dk4 wrote:
Sounds awesome! Now waiting for some real-world user reportsI can tell you that the surs of his converter are working great.
After yesterdays tests I told Schmackbolzen that his surs are nearly perfect, but you can go trough them if you find a right place/try hard enough.
However, I got some of his surs since some weeks and they work great. So my real-world user report gives a good mark for Schmackbolzens work until here
Some comment to StarTraders post:
The converter works best with already prepared convex meshes, thats what Schmackbolzen wrote and thats not the problem! Just use the convex tool of Milkshape and you won’t have any trouble with that part.
If I understood right you got some problems that his converter uses obj files. The fact is, that these files are supported by every 3d model program and converting a cmp to obj is not the problem, isn’t it?
Oh and, if you are not happy with “[…] put every convex geometry in a single group.” I will tell you that this is normal for a lot of other games, for example the Source Engine.
-
gives ST another carrot
i didn’t say its perfect or exactly what we need. but it is more than we ever had and is not the final version. i just don’t start with seeking for the imperfections, i am just a bit enthusiastic and looking forward for this tool to become the very one we need. it probably, even likely will be, don’t you think so? -
To clarify some things:
Convex meshes for physics engines are absolutely normal! Skotty knows this e.g. from valves source engine.
Every vanilla .sur is made out of convex meshes!
The converter just makes sure the geometry is as the vanilla physics engine needs it.
You can use non convex geometry, try it out. I even tested 3000 polygons, it does work!
I know there is no documentation for the options for know, because it is not easy explain it, since I would have to explain the algorithm and mathematics behind it.
I try to make it simple:
First you should know that for every connected triangles a convex hull is being created.
For the number: Imagine a vertex lies behind this convex hull and you enter the maximum distance allowed from the vertex to the corresponding hull polygon.
For the checkbox: There are cases where no corresponding convex hull polygon is found. In this cases the maximum distance is infinity. That’s why this option exists.
If you are satisfied with the explanation I’ll include it in the documentation.
Concerning the .obj format: Normally you get only trouble with texture coordinates and materials. Both are not needed. The .obj parser is from my own 3D engine and tested against over 10 exporters. It should read nearly every file there is now.
If there is an algorithm which can convert normal geometry to geometry consisting only out of convex elements I would try to implement it. But as far as I know not even the modeling programs are capable of that.
Are there still things which are not clear now?
-
well, for the options explanations, it starts to be somewhat clear. could you prolly explain it like what the different options would result or should result in in the end. maybe some examples and a link to your coming post in the documentation.
-
The result is either you get the convex hull of the connected triangles or every triangle will be made double sided and put in a separate group (I called it splicing), which is convex, because a doubled sided triangle is convex. This way geometry is preserved, but you get more data (that’s how vanilla does it!).
It would be best if you import the converted sur with Adoxas MS sur importer and examine the results. This should help you to understand.
I will develop this tool further depending on your experience. So try to understand it first, I even might change the gui. I don’t know how you guys are thinking so you’ll have to help me with that
-
I updated the main post with some explanations…
-
Good lord is it so hard to convert to OBJ? It’s definitely the way that makes the most sense since you should normally always keep a copy of your original models in some form other than CMP (3ds, obj, ms3d, max, etc.) for later editing, right? With OBJ you get a simple format that works with all tools (no recompiling twenty versions of a 3ds Max plugin because each SDK is incompatible with the previous one) and that isn’t limited by the often poorly documented and/or fleshed out APIs.
I think Schmack went the right way by not making this dependent on MS3D or Max. If a Max plugin was what you wanted, I don’t exactly get the problem. Max -> OBJ -> SUR. Oh gosh, an additional step!
-
FriendlyFire wrote:
Good lord is it so hard to convert to OBJ? It’s definitely the way that makes the most sense since you should normally always keep a copy of your original models in some form other than CMP (3ds, obj, ms3d, max, etc.) for later editing, right? With OBJ you get a simple format that works with all tools (no recompiling twenty versions of a 3ds Max plugin because each SDK is incompatible with the previous one) and that isn’t limited by the often poorly documented and/or fleshed out APIs.I think Schmack went the right way by not making this dependent on MS3D or Max. If a Max plugin was what you wanted, I don’t exactly get the problem. Max -> OBJ -> SUR. Oh gosh, an additional step!
I agree with this completely. Thank you Schmack for working on this tool for us. It will be invaluable in the modding process.
-
Thanks guys!
That’s one reason, the other is, that you should not use the model geometry for collision, but rather a simplified one. So it doesn’t make sense to use the geometry of a .cmp file anyway. You should at least run a poly reducer over it. And the more better way would be to make it like vanilla and rebuild the geometry with convex elements. For the lazy I implemented the splicing, for which I count myself in. In our mod I will try to use spliced geometry, we will have to test whether this results in too much server / client load or not.
-
C’mon ST, surely you’re just being rude. You can’t dismiss something just because it doesn’t conform to your exact specifications or preferred way of doing something. Sounds like you’re telling the guy off for daring to release a tool that’s not exactly how you would like it to be, he doesn’t work for you so you can’t fire him.
I’m steeling at least a weeks supply of carrots off you for being a bitch.
-
I think he is just disappointed ^^ I can understand it, but the reasons why I chose to write it the way it is now, is mostly Freelancers limitation of the .sur format and general collision mesh usage. I think as soon as he understands that he will see why I did it.
For further clarification I updated the main post again…
-
ok another test
- import cmp in milkshape
- export as an obj
- convert this obj in sur
- it works great
it takes me 1 minute … so if you want a “bubble” hitbox it’s just perfect
if not, as me ^^, you have to do by handi don’t have yet tested with a multipart ship but it’s on the way so i came back ^^
-
When unthinking people unjustly accuse me of being nasty and unkind, my fur lies flat on my back, my ears fold back, and my claws suddenly extend…
Why do those of you assume my comments were to Schmackbolzen and not to my pal Gisteron, who took it as it was meant?
Schmackbolzen, you are doing good work, and I very much appreciate the difficulty of this task and the effort you are putting in. I have said this already several times - it seems some here cannot read.
And I understand the reasons for your decisions, and the reason for choosing .obj format. Yes I know it makes the tool independent and it can be used for many modelling programs, and this is a good thing.
I have set out the guidelines and specifications that would make the tool complete, and yes, I will be disappointed if this tool falls short of making an identical vanilla sur, with the options that we need.
Why? Because the other tools all do that already, and we can fix those by adding the hpids to any surs generated with Sur Splicer or Sur Builder, or by working within Sur Exporter v1.1’s limit of 18 sur parts as it already adds hpids and complete with the correct sur shapes for each one too.
Finally it is up to you if you wish to follow them or do it differently, you are the proggie and you are not bound to me in any way. But remember the majority of people here have no clue about what is in a .sur file. The fact that they might be happy is NOT a good measure. They can’t be bothered to go through the pain of extended testing that I have done, in trying to understand why those attempts all failed eventually.
FF: Yes FF it IS a pain to have an extra step when I (or you in some future life) make surs for 50-60 models. It’s not a case of one extra step/click, so stop being a dumb arse. Count the steps and clicks, and repeat 50 times and let’s see if you think the same after even 20 exports. It already takes a lot of extra time to make the convex hull shapes and check them and remodel and do it again. So belt up and go make some more nice lighting and weapon hit effects, leave the surs to those who know the difference.
Until now we lacked the understanding and we still currently lack the tools. We finally proved that the surs are missing important parts, and now we know what those parts are. I also proved that sur parts with gaps between them also work, and this is invaluable to those who want to design bases with remote “island” modules. This tool will hoefully be able to make good surs for those too.
The rest of you seem to be happy with your incomplete surs, and when you have random crashes you are happy with just restarting FL Server. So - be happy.
I am not, I want my (and your) surs to be as problem-free as possible. 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?
Go think.
Anyway this is my final input, I won’t be dragged into another fracas, and I don’t take kindly to being scoffed at when I am doing things for the common good and benefit to all.
Schmackbolzen, again my thanks and well done for taking this on, it is a difficult thing to achieve. I would be very happy if you choose to follow the specs, it is to help you to make a complete tool, for every modeller who uses it in future,and many are only now getting interested in making mods and new ship models.
One more advice please if you will - please teach a native English speaker what you mean and what your tool does, and let them write the documentation, there are a lot of misunderstandings so far in your description, and it is not your fault but you don’t have complete knowledge of the language, it is not an easy thing to achieve. Thanks again.