Compeller
I think perhaps what I'm seeing here is that the engine is scaling the mdl to be x meters long, and then scaling the cvh to be 1.1*x meters long, or otherwise adding a fudge factor. I'm not sure about the details yet, but changing the scale of the entire cvh won't make a difference.
Last edited by Compellor on Wed Sep 23, 2009 10:29 pm, edited 1 time in total.
Any job worth doing with a laser is worth doing with many, many lasers. -Khrima
Beyond a shadow of a doubt if you don't watch them like a hawk they will stack their collective balls off - MrChaos on Alleg players
Beyond a shadow of a doubt if you don't watch them like a hawk they will stack their collective balls off - MrChaos on Alleg players
engine scaling is performed like this:
inputs:
in the cvh file of the station, 1st line, 1st number = OriginalRadius.
in the core file, for the station, the desired radius: Radius. This field is incorrectly labeled 'Scale' in ICE, it should be labeled 'Radius' (i'll fix that in next ICE version) since it's the final value of the radius of the station.
output:
the scale factor is simply : scale = Radius / OriginalRadius
then all CVH values (positions, doors positions) are 'scaled' by this scale factor ((x,y,z) = (x*scale,y*scale,z*scale)).
Example:
the IC gar:
model = ss27.cvh -> OriginalRadius = 29.59420013
Radius ('Scale' in ICE) = 423.5
scale = 423.5 / 29.59420013 = 14.31
so 14.31 is then multiplied to all 3D position vectors of the CVH file (including launch & garage positions).
edit:
For ships, the same scaling method is used but the 'Scale' value in ICE should be read as 'Length' (or Diameter) instead and so the formula is:
scale = Length * 0.5 / OriginalRadius
inputs:
in the cvh file of the station, 1st line, 1st number = OriginalRadius.
in the core file, for the station, the desired radius: Radius. This field is incorrectly labeled 'Scale' in ICE, it should be labeled 'Radius' (i'll fix that in next ICE version) since it's the final value of the radius of the station.
output:
the scale factor is simply : scale = Radius / OriginalRadius
then all CVH values (positions, doors positions) are 'scaled' by this scale factor ((x,y,z) = (x*scale,y*scale,z*scale)).
Example:
the IC gar:
model = ss27.cvh -> OriginalRadius = 29.59420013
Radius ('Scale' in ICE) = 423.5
scale = 423.5 / 29.59420013 = 14.31
so 14.31 is then multiplied to all 3D position vectors of the CVH file (including launch & garage positions).
edit:
For ships, the same scaling method is used but the 'Scale' value in ICE should be read as 'Length' (or Diameter) instead and so the formula is:
scale = Length * 0.5 / OriginalRadius
Last edited by KGJV on Wed Sep 23, 2009 11:55 pm, edited 1 time in total.
-
raingriffin
- Posts: 145
- Joined: Wed Jul 01, 2009 12:23 pm
- Location: Italy
the mdl mesh isn't used for collision detection (and so for 'docking' detection).raingriffin wrote:QUOTE (raingriffin @ Sep 24 2009, 01:51 AM) KG, does that include the mdl mesh or just the cvh?
the scaling of MDL mesh is done in the 3D rendering engine so it's another code (it should be roughly the same i guess) but i didn't check how it's done.
Hrm.. Ifyou could look at that, that'd be extra nice so that we could confirm/deny whether there is a "fudge factor" or something else that's causing issues with the scale of CVHs compared to the MDLs for bases.
I've not seen many issues with excessively large ship models, however, so I'm not sure if it'll be different
I've not seen many issues with excessively large ship models, however, so I'm not sure if it'll be different



QUOTE in the cvh file of the station, 1st line, 1st number = OriginalRadius.[/quote]
I'm not sure whether this is a real solution or if it'll have unintended consequences, but if you create a cvh which should be hull-conforming using Milkshape, then tweak that value in the cvh using a text editor, I'm pretty sure you can get a truly hull-conforming cvh. I doubt there's any particular rule telling you how much to tweak it by, it'll just have to be trial and error.
I did manage to get a hull-conforming cvh for a cube this way. Cube had a cvh radius of 3, and the core radius was 300. Using screenshots, the grid, and the known length of my scout, I estimated that I was impacting the cvh 85m away from the visible face of the cube. That meant I needed to increase the radius in the cvh from 3 to approximately 3.8. That almost worked, but now I was flying a meter or two inside the cube before impact. I changed the cvh radius to 3.7. Now I was impacting a few meters from the visible hull, but that's a huge improvement over 85 meters. I then used the cube as a teleport, radius 60m. At that scale I couldn't tell that I wasn't quite impacting the surface.
I'm not sure whether this is a real solution or if it'll have unintended consequences, but if you create a cvh which should be hull-conforming using Milkshape, then tweak that value in the cvh using a text editor, I'm pretty sure you can get a truly hull-conforming cvh. I doubt there's any particular rule telling you how much to tweak it by, it'll just have to be trial and error.
I did manage to get a hull-conforming cvh for a cube this way. Cube had a cvh radius of 3, and the core radius was 300. Using screenshots, the grid, and the known length of my scout, I estimated that I was impacting the cvh 85m away from the visible face of the cube. That meant I needed to increase the radius in the cvh from 3 to approximately 3.8. That almost worked, but now I was flying a meter or two inside the cube before impact. I changed the cvh radius to 3.7. Now I was impacting a few meters from the visible hull, but that's a huge improvement over 85 meters. I then used the cube as a teleport, radius 60m. At that scale I couldn't tell that I wasn't quite impacting the surface.
Last edited by Compellor on Thu Sep 24, 2009 2:59 am, edited 1 time in total.
Any job worth doing with a laser is worth doing with many, many lasers. -Khrima
Beyond a shadow of a doubt if you don't watch them like a hawk they will stack their collective balls off - MrChaos on Alleg players
Beyond a shadow of a doubt if you don't watch them like a hawk they will stack their collective balls off - MrChaos on Alleg players
I don't know how you would do it in MS. Just shrinking the thing and exporting doesn't work.
Any job worth doing with a laser is worth doing with many, many lasers. -Khrima
Beyond a shadow of a doubt if you don't watch them like a hawk they will stack their collective balls off - MrChaos on Alleg players
Beyond a shadow of a doubt if you don't watch them like a hawk they will stack their collective balls off - MrChaos on Alleg players
Hrm... Been playing with the numbers a bit. Increasing the radius seems to "bounce back" after a while. I used the radius as double what it should be, and I'm ending up with a CVH that's quite a bit larger than it should be. However, when I put the radiius as the same number as was in ICE, I got a nicer, more form-fitting cvh than before (However, there was up to a 20m difference)
EDIT: Well, apparently you have to reload the client as well. Oops. I just reloaded them both and the entire hitbox is.... abotu 10m across.
EDIT: Well, apparently you have to reload the client as well. Oops. I just reloaded them both and the entire hitbox is.... abotu 10m across.
Last edited by Andon on Thu Sep 24, 2009 4:32 am, edited 1 time in total.



-
raingriffin
- Posts: 145
- Joined: Wed Jul 01, 2009 12:23 pm
- Location: Italy
Milkshape doesn't give any big degree of precision in CVH making. All it does is really just exporting a normal mesh coord into the cvh file. You just create a number of non convex meshes to use as a collision skeleton and name it cvh_# that is all there is to it, this, in theory makes it easy to create a snug hitbox. In practice mdl/cvh distance in game is vastly different than what you model in MS. I suppose that's due o the scaling factor being different. For example, i tried modelling the CVH meshes to be slightly "inside" the mdl (almost superimposed) and in game i'd still impact before i reached the visible surface. I am amazed at your maths guys ^^ wish i would be able to estimate distances that way, but i don't know what your points of reference are, also i could try scaling by editing the cvh but all the corrections i made so far (i have completed the GT pali and res fix as well, but just with my rough method) were done by testing it in a lan server. I would do a change then reload both server and clients and start a game to try it out (it does take a couple mins to get the constructor and a bit mor to plant it
) i know i have no method whatsoever, but it seemed to work
It looks like my working skills to fix the doors are a little too much on the rough side tho, so i think i'll leave it up to someone else, still if you want the fixed versions i made for the other gt bases, if nothing else, to test them just let me know, i'll make them available. (gt garr, not very well done, gt pali and res tested out with kramari on a public ad hoc serve resulted ok)
It looks like my working skills to fix the doors are a little too much on the rough side tho, so i think i'll leave it up to someone else, still if you want the fixed versions i made for the other gt bases, if nothing else, to test them just let me know, i'll make them available. (gt garr, not very well done, gt pali and res tested out with kramari on a public ad hoc serve resulted ok)
Last edited by raingriffin on Thu Sep 24, 2009 7:20 am, edited 1 time in total.
-sing- Just always look on the bright side of life -whistle, bow to monty python's Life of Brian-


