CMPs with over 18 parts
-
the 3ds max exporter has no limit on the amount of mesh groups that can be exported.
-
Thanks for the info, I’ll search the forums and see if I can find it.
Also, I’ve been making a test run - as it usually happens with sur files, I got unlucky in the end. Here’s what happened:
I have a complex 3d model (about 70 separate groups in MilkShape). I thought it’d be a good testing model.
Exported as single-component 3db
Ran ConvexTool, done everything according to the tutorial, except that I named every object “Root”
Exported as OBJ, ran OBJ-SUR converter
Checked the 3db option (assign to None), checked Static for every group
Sur file created.
Test: Everything is fine, except absolutely no collission detection.Exported model as CMP, added HpMount manually using HardCMP (without HpMount, the model won’t appear in-game)
Re-built SUR file, this time without the 3db switch. All objects are assigned to Root and all are Static.
Sur file created.
Test: I do get collission detection on -most- parts, but not all of them. In HardCMP, every sur part shows nicely.What could it be? The mesh contains some identical parts (cylinders), and on most of them, collission detection works fine, but on others, it just won’t. Could it be ConvexTool making an error somewhere?
I do admit this is a complex model, but I wanted to see if it’s worth toying around with odd models for scenery. Note that I don’t want docking, animation, only a complex scenery object with collission detection.
-
Only 7 materials, but note that by ~70 parts I meant ~70 groups in milkshape.
Once exported to cmp as single-component, it will only contain one VMeshRef - the Root.
But, as a sur file, there is a convex hull generated for all ~70 parts, so in the end, you get a sur with ~70 convex shapes, all attached to a single cmp part, the Root. The thing works - only a few parts don’t seem to register collission.
-
I’ve done models with upwards of 1000 groups in 3ds Max. With the new exporter, it wasn’t an issue.
As for the .sur file, that’s a bit more complicated. It is a known issue that not all portions of ships will register hits.
-
I think we still dont have enough clarity on how the sur files work, if we understood better it will make our decisions easier on how to build them…
Can anyone confirm which of these suppositions is correct:-
a) the sur file defines the zone where checking for collisions begins once a foreign object penetrates it, but no collision is made. Actual collision is only made when the foeign object actually hits on the model surface inside the sur zone. In close-fitting surs this might be a very small difference (or even the same).
or…
b) the sur file is the actual surface where the collision is made when a foreign object hits on it.
And can someone define the purpose of the shield bubble in the fighter cmp’s? Is it only to splash the visual hit effect on it when shields are up, like a glass outer bubble swilling with coloured liquid only for visual effect - if we made it huge, will the hit flash then be the new size of the shield bubble?
Or is it just an outer collision detection zone like option a) above, once it is penetrated then to start looking for collisions on an inner sur or on the model surface?
And what is the purpose of the shield sur itself (e.g. li_elite_shield.sur), is this the size of the visual hit effect when the shields are up, and not the shield bubble?
This isn’t clear because the ship shield bubbles and shield sur are the same size and shape for the fighters in vanilla.
Some games use only very basic, large outline shapes like rectanguloids for collision detection, and these only start the collision detection sensing, the actual collision only happens when the surface of the actual model is penetrated.
-
Sur files are both, surface and penetration detection.
Shield Bubbles or the wrapped meshes of surs (so the outer sur mesh that cover the whole ship) is just for collision detection, no collision itself. If any object penetrates this outer mesh, the inner meshes get enabled and will collide with the foreign object.
-
Got it, thanks. I’ll have to do some experimenting when I get time.
-
@Skotty.:
If any object penetrates this outer mesh, the inner meshes get enabled and will collide with the foreign object.
Explain it, please. If I understand right shield bubble is for detection only but it’s value also decreasing if something collides with it. Shields and hulls have different values, if the shield down the hull will detect the collision or the hits …etc.
So, how do the inner meshes work with the collisions on the shield bubble? I’m confused. -
The shield and hull are the same collision. If you collide with something, you get damage. Its the same damage on shields or the hull.
-
Well, I’ve been fooling around with this for, well, years by now, so I guess I’m going to ask you to help me out directly, for I guess I’m out of luck.
I’ve been looking for a way to get planetary surfaces into FL in an actually working manner. Visibility problems can mostly be solved by adjusting some values in the EXE, but I’ve mostly been out of luck with the surface file. I’ve been looking for a somewhat reliable automation for planetary surface creation, so it might not be 100% form fitting, but getting it to work would be a good start.
If any of you can get this working for me, and tell me how they did it, I guess I’d owe you all a cake or two.
And just so that I’ll give something in return as well:
An excellent toy to play with - Hierarchical Approximate Convex Decomposition.
https://code.google.com/p/hacd/
Go to source and do an svn checkout on the address provided (using for example TortoiseSVN). You will get a working application.Well, here is the topic of my years-long despair:
http://dl.dropbox.com/u/34513151/Terr.zip
Any help appreciated