.obj -> .sur converter
-
Well, if I understand you correctly, the only thing which is missing for you to have it completed is the multipart stuff. This in fact is easily added, but I first have to make some code cleanup to allow multiple parts. Also I don’t like to release a new version with known errors so I most likely will fix the most of them before actually adding multipart support.
Also as far as I can tell nobody seemed to have understood the format as I do, since there is no tool which could create a bit section that worked. The collision speedup speaks for itself. But we shouldn’t forget that there are still parts which are not fully reversed (e.g. the ref. vert. stuff, the numbers in the vanilla .sur files don’t make sense for now). Also Adoxa + LS helped a lot with reversing most of the file structure.
There is no guarantee that we ever will be able to make identical .sur files. The fact that so far no one could create a working bit section before I started makes it highly unlikely that we ever will be able to reverse all of it. If we are lucky an approximation is enough and it will work for the most of the custom files (concerning the bit section this seems to be the case here).
Also keep in mind that all of the vanilla .sur files seem to be generated by hand and this is what you also should do. Read up the basics of physic engines and you will understand why. They all need convex shapes and don’t work with polygons. The reason that conversion works is the trick I adapted from the vanilla .sur files for single polygons but it is more computationally intensive as a result.
Also this is the reason that I didn’t write a .cmp converter. If you just convert them to .obj and then to .sur, fine you can do that, but this is not what you should do. The original geometry is usually not meant to be a collision mesh. Also I don’t want to write x exporters for different programs, hence I choose the .obj format (for which the reader actually is modified from my 3d engine so I didn’t have to start from scratch).
Most of the points I already explained. For me the new feature of the converter was, that you actually could convert any geometry (well it turned out that some does not work) which no tool could do up to that point. The rest was just usually bugfixing plus adding new features afterwards (that is what you are waiting for). Also I only wrote it, because I was annoyed that no one could create a real working .sur tool. I guess they all just gave up because of lack of motivation or they didn’t have enough knowledge for it.
-
I don’t recall whether you have added command-line support, Schmack, but that would alleviate any speed concerns as a simple batch script would make the conversion a one-step process no matter the number of files required
-
I guess it would be even easier to just include batch processing in the program itself, the code for walking through all the subdirectories do I have lying around anyway. Noted for the next version
-
StarTrader wrote:
Blah blah blahST, your perceived entitlement to these resources is getting ridiculous. I’d hardly call what you do “cajoling”; it’s borderline harassment.
This tool works very well and, in its current form, a staple of the FW:ToW mod. Yes it doesn’t do “everything” but with some concessions, it does more than anyone else has done previously.
Just be patient and stop being a prick. Schmack will get to it when he can.
And please stop with the “children” garbage. It’s getting rather tedious. It’s also ironic, as it’s you who is acting like one.
-
Sushi you surprise me. I thought you were more mature.
Entitlement? Utter Rubbish, where do you see that claim from me?
My previous question was over a month ago and there was no news since.
As only one other person expressed any interest I assumed that only he and I were interested and that therefore Schmack would probably not be interested in developing a new version for only 2 people.
I wouldn’t be, that is for sure.
You may have observed that I have kept a very low profile in the rest of the forum for some time too.
So I think I was not out of order in asking for news on this remaining subject which is of interest to me.
Fine, so you have used the existing utility for your own mod.
Good for you.
So since you think you don’t need an improved version then the current one is fine for you. Right?
So you’re out of this discussion since your needs are satisfied, right?
Well I did all of mine manually, over the past 4 years, and twice and even three and four times over. A good satisfying result for me, but a heck of a lot of long nights, cursing and failures before I managed to get a good set, and not for all ships. My tough luck. I’m not complaining, I took it upon myself to write a complete mod alone and I did it and released it. I am happy that I managed it, not bragging. But i was convinced that my surs were still causing my random intermittent crashes.
And then suddenly, LS comes up with his Sur Builder. Wow! Ecstacy! So I waited and encouraged him by doing an awful lot of testing and producing conclusive test results - alone again, and in vain. Sad that it too was dropped, could it be because of lack of expression of interest from others, methinks?
And then after more months, Schmack very kindly agreed to produce a better tool, and has done so as a first version. This is great.
And Schmack has included the missing HpID table so surs no longer cause those random intermittent crashes.
Yes, Schmack’s tool is now producing good 1-part surs. But it doesn’t yet do multipart and does not place Hp hit detection shapes into the sur.
This is causing no hit detection on mounted weapons, right? Despite the weapons having their own sur files.
No problem? OK, for you.
And Schmack has informed us that there are other unkown areas too. This is not surprising or else others would have also found the method. In my opinion too, he and his advisers have done extremely well in unravelling the darned thing to this degree.
All this is fine, I didn’t get any bad reaction from Schmack, only from you and a couple of others.
Odd that.
Don’t like my sarcasm in this and my earlier posts?
It’s because of my disappointment that nobody else actually stated that they are interested in Schmack developing the tool, and then suddenly you all are, but jump on me for pursuing it - for you too!
I suggest you give up antagonising me, and let Schmack reply in his own way, and we can then all see what he is prepared to do, and when he thinks he can manage it.
How is this harassing him? I’ve not pressurised him, I have just asked him and I am asking only to know for myself.
You and others will also benefit from any development that Schmack makes, so you should be pleased that someone has expressed an interest to keep this going if Schmack is willing and able to do so.
If he isn’t able to do so within the next few months, then I just need to know so I don’t continue to hang around outside this particular door.
-
StarTrader wrote:
Yes, Schmack’s tool is now producing good 1-part surs. But it doesn’t yet do multipart and does not place Hp hit detection shapes into the sur.
This is causing no hit detection on mounted weapons, right? Despite the weapons having their own sur files.
Yes. And if you actually read the thread you would see that we came to that conclusion several times now - and Schmackbolzen has repeatedly said that he will add these two things when he has time.
Now, what’s your problem? Seriously?
I and everybody else are also waiting for the fixes, but we dont take the pretentious attitude and say that others dont give a damn.You know, you could simply have asked for an update from Schmackbolzen but that would have been too less of a drama, right?
Congratulations - mission accomplished in that regard. -
Actually one here wrote that he only used 3 (?) HpID names and had no crashes. Thus just leave the weapon slots out and you get your hits. If more can verify that I can add to my first post which HpID Name(s) you need to avoid crashes.
P.S.: From my vast (^^) experience as FL Server Admin for our mod I am used to people not responding etc. Most of them keep quiet until something is wrong. Only the minority thanks you for your work (which is always good to read). Also I don’t take posts to personal/serious since one most likely will not understand the written text as the other had meant it. This always leads to stupid fights in our forums until it is solved later via Teamspeak…
-
I can confirm that, at least so far, just using a handful of HpIDs (no weapons), we have had no crashes, perfectly working SURs and hit detection on weapons. w0d has theorized that the weapon hardpoints may be used to speed up collision detection for weapons; a good thing to have, but not essential. This sure makes sense if you look at how they’ve been behaving so far.
ST, I’m tired of your incessant rants on the subject. Anything you’ve said in your past 10 posts, you’ve already said too often to count. You want it. WE GET IT. Now stop polluting the forums with this and do something productive. If your post(s) had been about thanking Schmack and asking for progress, I wouldn’t have minded, but you have to slander, bullshit and insult other people along the way and that I can’t accept. Stop it or there will be consequences.
-
Well, here’s a minority thanking you for your work Smackbolz. DiscoveryGC 4.86 is coming along smoothly on the modeling side, and most non-multipart models have been given a new, tight-fitting SUR using Milkshape and your tool.
We’ll hold off with the dockable and animated ones that still need a better fit, until your tool has functionality for that. Old clunky spliced surs until then - just means you can’t use many parts.
-
AeternusDoleo wrote:
We’ll hold off with the dockable and animated ones that still need a better fit, until your tool has functionality for that. Old clunky spliced surs until then - just means you can’t use many parts.Actually, you can create hitboxes with unlimited parts. Tutorial his here: http://the-starport.net/freelancer/forum/viewtopic.php?topic_id=2017&forum=26
If the video isn’t there I’ll upload tomorrow.
-
Schmackbolzen - please contact me via PM if you would like to, I am tired of these argument-hunters. They can give out piss and sarcasm but can’t take it. I am only interested in your development of this tool, if you can then I will be delighted, if you can’t then I understand. Many thanks as always.
StarTrader wrote:
Hi SchmackbolzenThe holidays are in full swing as far as I know, and hopefully you are enjoying your free time too.
If you will continue with the converter to make it multi-group, and maybe add the basic hardpoint shapes that the original exporter already puts in (but this is not essential for this converter as long as the HPIDS are included), then you will have two dedicated and grateful fans.
Only 2, because clearly nobody else is interested, no-one else has said so here or anywhere.
So clearly they do not want it and will not use it even if you do complete it.
As you know I have been criticised by several members for being selfish in asking for it before, since nobody else really wants it, so it is only for me and now Ezekiel also said he wants it.
Nobody else said they want it.
Not FF, not W0dk4, not the Discovery developers, not any other team developers, and not anybody else either.
So nobody else needs it.
Not for their current mod, and not for any future mod either.
So this means all your work will be only for me and for Ezekiel.
Yes, I am rubbing their faces in it.
So I have an idea - I might be able to pay you a moderate commission to develop it only for me and for Ezekiel, since nobody else wants it.
In this case of course, you and I will own the rights to the converter, and I will not release it to anyone else, only to Ezekiel, under a no-distribution agreement, and I will ask you to not release it to anyone else without my permission too.
But if you do not want to continue with it in the next month or so, then no matter - but please say so now, so that I don’t continue to hang around waiting any more.
After all, only I and Ezekiel really want it.
And my need is for my personal use only.
So I await to know if you will continue shortly please.
I know that when the next term starts (or if you start in a job) you will not be able to work on it.
Many thanks.
Why would anyone develop anything if they don’t see adequate support for it?
This is what I wrote. Yes I prodded and poked a bit, to encourage the others of you silent ones who are also waiting to say so.
The antagonistic response of some of you was ridiculous.
Incessant? Since when? And I am not the one to be accused of slander, FF. Go read.
You have developed a habit of responding badly to me, no matter the subject. This is biased and immature, I don’t care if I am in your “bad books”, you have a really bad attitude problem not only with me but also with several other people and it is unwarranted, and it’s all yours to grow up and resolve. Stop threatening that it’s your server and that there will be repercussions, this really is childish.
-
ST you can sepparate the sur into multiple groups manually with a hex editor if you really need to make the multi-part sur, its a little more time-taking but will work (i made for a 2-part turret, when the sur builder failed to make the 2 parts properly).
-
Thanks Cata123, I know, and there are of course other ways to do this too.
But we need a tool that will do all of this, because of the time the other ways take.
-
Since using this sur maker, I’ve come across a error that I don’t understand. When ships run into each other, there is a large amount of lag or the game crashes all together. The same happens in mission against the ships. Here they are if someone would look into it for me. Note: They use vannila weapons.
-
Alucard, do your surs use the Hpid hardpoints section? If so, you’ll need to remove them or you get that lag you’re describing. FW:ToW had a similar problem.
-
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.
-
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.