CMP to SUR Conversion Tests
-
**I have added a few extra controls to the program, go to the following link to get it…
http://digitalbrilliance.com/modules.php?name=Forums&file=viewtopic&p=3318#3318**
-
Ok… quick test after reading this… yep 144bytes & HCMP crash…
also … it didn’t shut down properly… just stayed working till i manualy shut it down with task manager…Nice options though LS… certainly getting there 8-)
-
It will be remedied tonight, most likely due to the changes to support the multi-part surs that were disabled for this release…
-
Davis wrote:
I have a really rookie question, but: Those ships you made surs successfully, as same flat as this Jalthi?Yes some were flat apart from one or two vertical fins.
Thanks LS.
-
Well, I tried the tool yesterday (it’s a hell of a resource hog, FYI) on a damaged solar I’m including in my mod (one part, so it fits). The SUR works fine, but it’s quite a bit different than… well, perhaps I should explain.
My new solar is basically a damaged dock, like the two you see on the Freeport station models. I took space_police_dmg.cmp, chopped off the habitation part on top, and wallah! I created a SUR for my new model, as well as for the vanilla model (as a test).
From what I can tell, the shrinkwraps are identical between the vanilla SUR and the custom SUR, but the vanilla SUR has additional groups when imported into Milkshape. When looking at it in HardCMP, the vanilla SUR has components inside the shrinkwrap that conform to the CMP perfectly; the SUR generated by the tool has only the shrinkwrap. The SUR for my custom model, too, has only the shrinkwrap.
It seems to be non-trivial, as the inner part is the defined surface in the vanilla SUR, but the shrinkwrap is used by the generated SUR. Will the tool, in the future, be able to replicate perfectly the SUR from vanilla FL?
MK
-
**The latest version has been fixed.
@ mknote - the current sur builder only creates a shrinkwrap sur, nothing more. The multipart sur code is already in the process of being built. It may get to the point of making form fitting surs but that will depend on how long I will continue working on it. I do have a game engine that I need to get back too… Doing form fitting surs would require that I learn another branch of mathematics dealing with mesh decomposition. The program was never meant to completely replace the sur splicer and sur exporter, it was just meant to offer an alternative way of making them.**
-
Yep it works on the Jalthi too by disabling secondary sort as you said.
Thank you bud.!
Look forward to the multi-part one, let me know whenever you need some encouragement!
-
So has anyone blown their mod up yet?
-
lmao… not with this… no… hehe
Still yet to test this new ver m8… on the hunt atm… johnny rico style
DESTROY ALL BUGS!!!erm, sry been a very long day 8-)
-
Forget milkshape as its deceptive where sizes are concerned. Use FLmodelTool and check the radius of the model. If its smaller than 15, it’s a small model. You can happily use the 0.1 setting in the sur builder for anything, all it does is create a slightly more complicated sur
-
LS -
Just a note to recap what we’re - OK, just me, so “I’m” - expecting, in case there is a misunderstanding and one or more of us is disappointed…
When you can detect out the separate groups in the cmp and make shrink-wrapped sur parts for each, we will get…
1. Automatically convex surs for each MilkShape part.
2. Where there are gaps between ship parts such as booms etc there will be no sur in empty space if each boom is a separate MilkShape part.
3. an optional shield bubble for our small ships?
4. A second sur for each wing as per original FL surs?
5. Compound surs for wings+weapon points?
6. Double surs for each HpEngine, HpCM, HpMine, HpMount etc as per original FL surs?
I am even happy to have a selection pane where I can check the parts that I want double surs for (e.g. left wing, right wing, left wing +HpWeapon02, right wing+HpWeaon03, etc, if it would help the process.
In this way there is no need to work out Flavian or Neroic Maths
because the modeller has to split his .cmp model into enough groups to ensure there are gaps where there should be.Even I can do that, so let the others do it too!
The good side-effect of this is that those parts fly off individually when the ship is exploded - Nice!
The other still-undetermined statement is that only the Root sur has to be convex - if this is the case then your tradelane ring and other surs can be easily made, the solid part can be convex, and the rest can be odd-shaped and be concave or even bent - but I still don’t know if this statement is correct and true.
Can anyone make some good controlled tests for this and report back? Or has anyone already done it and can really confirm that the standard tradelane ring sur can be one solid middle part and four tubular “horns” bent round the ring shapes and meeting at the top middle and bottom middle?
Thanks all.
I really want surs that meet 1-6 above, because I see that as the way to make fully working, reliable surs that follow the ship’s contours closely.
By splitting my models carefully and allowing LS’s generator to make close-fitting sur parts, I think we can more easily achieve this. Making auto surs to fit a lazy person’s single-part holed model is probably going to delay this project indefinitely, and is not a requirement as far as I am concerned.
And as always, very many thanks for the strong efforts you are putting into this, Lancer.
-
I too think that development time may be better spent in allowing the modeler to create custom surs on their own (like, not automated), having a sur tool to actually build an FL-like surfile rather than doing it the old “barely working” way.
For example, what about those sur LODs? Are they just a myth or do they exist? If so, how to use them or can you write a tool that could allow modelers to insert their hitboxes into the different LOD stages?
-
**@ W0dk4 - Im still out on the sur lods, the layout of the linkage in the bits section seems to suggest something along those lines but it may just be connections between the parts of the sub-surs.
As far as the manual building of surs, probably the best way would be for someone to fix the ms exporter (the latest one) and implement the stuff that has been found. I have looked over the code for it and it isnt that far from being repaired.
@ ST
1 - yes
2 - yes if its exported as a separate group
3 - possible but isnt it just as simple to attach a shield bubble in the shiparch entry?
4 - every part of the ship exported as a separate group will have a second sur attached, hardpoints on them will be automatically added to them, the root sur requires all of the sur parts to be part of it to work properly
5 - see #4
6 - what is the double sur used for? If it’s not on the root node of the mesh it will happen automatically…Selection panes - probably not, I would have to implement alot of handler code to add that into the program which could delay the project up to another month
The root being convex - have not tested that with the current code, been very tempted, if it isnt a requirement I could simply do a form-fitting sur on all of the parts and be done with it simply using Delaney triangulation.
Ok, here is the plans for the program that I want to have completely working…
Multi-part surs - in process, part of the code has already been written
Mesh decomposition - this may or may not happen, what this will do is split the mesh up into constituent parts until a convex hull can be built around each part. This will take care of any holes in a mesh simply by breaking it into small enough pieces that don’t have holes. I will be using Delaney triangulation to act as a mesh reduction feature and also another mesh reducer such as threshold angle face combining. The downside is that it takes alot of time to do that.decomposition example pic
From - http://www.codesuppository.blogspot.com/
Anyways feel free to continue posting your ideas, Im always open to new ones.**
-
1st TY 4 that great tool m8.
2nd 1 or 2 suggestions:An option to get a more ‘dense’
and possibly ‘closer wrapped’ SUR.Example #1:
If i have a very simple shape - say a ‘Borg Cube’ -,
it gets me ‘only’
a very ‘simple’ SUR
with a very few lines shown in the animation screen.
My impression is, we get collision detection only,
if the SUR has enough edges or ‘lines’ as shown in the animation.
Now if that model is big enough, it seems, a small ship
can sometimes slide through between those few ‘lines’.Example #2:
If i have a more complex, big structure with interior- say something like ‘Deep Space 9’ -,
it gets me a more or less ‘only’ a sphere from the outer part.
Would be cool to have the collision detection
with things like the arms on one hand and also
the inner structure on the other.
- say something like ‘Deep Space 9’ -,
-
thx Gibbon
a little feedback
i done 262 ships for the freeworlds french mod and … all works
so -___- it’s really really impressivebut i have a question
i place the ships as a base to test the hits and hull collision
all is working, but the hits are no longer visible at all, at maybe … 10/15 meters
so for a capship you don’t see the hits anymore.
it works because i added hit_pts to the cmp on the solararch.ini and i can see the life who come downso normal ? it’s due to the new hitbox ? or it’s something else ?
-
Hi LS, thanks for the explanation…
My replies to your queries…
3. Yes the shield_link is always needed in the shiparch.ini file, but as you know standard FL fighters always have that darned double shield-bubble (the HpMount 0xF00FB9DE and its twin with an offset value instead of mesh name crc) in the sur as well. I don’t know why, but it is compensated by FL if it does not exist in the sur, and the hits are shown flashing on the shield-link shield bubble until the shields are down just like if the shield bubble did exist in the sur.
6. Again I don’t know, although Bejaymac has tried to explain so many times that one is for collision detection and one is for weapon hits damage. One uses the mesh name crc and its twin uses an offset value like 0000270. These ones with an offset value instead of a mesh name crc are placed at the origin by the MilkShape sur importer instead of over the cmp part as they should be - HardCMP does, maybe it’s because the sur importer is not interpreting the offset values correctly if at all for these? So maybe by looking deeper into the HardCMP code you or adoxa would be able to understand the offfsets that are used and we (well… not me!) can then fix the sur importer too?
On duplicate surs for every non-root part… Well - not all cmp parts (other than the root) have the double surs. Only the wings, engine hardpoints, equipment hardpoints and weapon hardpoints do have them, and in case of weapons they only have them if they are mounted on the wings, and this becomes that convex sur covering both the wing and the weapon sur. You can see this complex sur even in HardCMP but it’s hard to distinguish, the best way is to import a sur into Milkshape and then you will see the double surs are all at the origin, just move them out one by one to see the shape they cover. The weapon surs are all extended tapered cubes, and the wing+weapon surs cover this extended tapered cube plus the wing it is sitting on.
Non-root hull parts and pylons (e.g. as in the stiletto and sabre) do not have double surs. So making double surs for everything except the root may cause problems.
And on only the root sur part needing to be convex… Well if we can determine that indeed only the root sur needs to be convex then it would be a terrific relief, as all non-root surs can be concave and be bent, and follow hull and body contours, as in my suggestion of a standard-shape-tradelane sur that can be then made of only 5 parts - a convex root sur part for the middle and four long, bent, tapered horn sur parts meeting at the top and bottom of the rings - easily and quickly made from copying each of the ring cmp quarters. However in standard FL ship surs, these sur parts are all indeed convex.
So it is worth spending a couple of hours proving this out, as it may save you lots of time.
Thanks as always pal.
