Jump to content

WIP: Saturn V S-IC (First Stage) v0.4 (Normalmap improvements)


CoolBeer

Recommended Posts

After seeing the Rocketdyne F-1 Engine and wanting to do a proper "Apollo Style" mission, I got inspired and wanted to build something. I downloaded blender and started working... Some time later, after many hours of cursing the learning curve of blender I had something working ingame, then after a few days of polishing/remaking it a few(many) times, releasing and updating it a few times, this is what we have today:

7gAjOLg.jpg

And ingame:

ZRtvkVg.jpg

(Showing both the default(USA) and the alternative KSP texture).

This is a full scale model(10m diameter base, 14m wide including the engine fairings and 38m high(total listed height of S-IC is 42m, the missing length is the engines)).

In game this is scaled to 6.4m, 5m and 3.75m. I have also included a 10m version, though it doesn't really play nice with the physics engine.

The 5 and 3.75m versions are not able to fit bigger than 1.25m engines(well, you can fit 2.5m engines, but it clips and looks silly), limiting how much thrust you can fit on it and therefore how much fuel is reasonable considering weight(no use pushing below 1.00 TWR really).

The 6.4m version does fit 2.5m engines, making it much easier to find suitable engines for lots of fuel.(5 x Mainsail == 7500kN thrust).

Fit's the F-1 engine nicely, though you need to resize the engine to match the scale. (I tried running a full scale model in game, it wasn't good...)

Technical stuff: The model is made of 1142 polygons(606 for the base and 134 for each of the engine fairings), the textures(paint and normal map) are 1024x1024px. I have stacked uv-islands where I could to keep up the level of detail though it would have been easier if I could have used separate uv maps for the paint and the normal map. It is untested how it performs on anything but full texture size(may or may not go horribly wrong).

It is also not 100% accurate, there are decals and stuff missing still.

Fuel amount in the tanks is very WIP, I tend to change the values to fit my needs, balancing TWR vs dV, so feel free to post what you think are the appropriate values.

The 3.75m and 5m tanks were filled so they were able to lift something with stock 1.25m engines while the 6.4m engine were filled to keep in line with my current progression of my Apollo Style mission(still to be launched).

The stage fits nicely as the bottom of the Apollo Mission Pack Saturn V, the textures don't match though(mine is brighter), you will have to adjust the fuel level and you'll probably have to do some engine modding to match their engine(2,275kN thrust, divided by 5 is 455kN per engine, their isp is 475(atm)/525(vac) and weight is 8t/5 == 1.6t each). You can use their engine cluster, but it clips with the engine fairings.

Compared to NovaPunch2, the tank is underfilled, if we compare with their biggest tank(5m x 12m == 235.62 cubic meters) it contains 78.23 liters liquidfuel per cubic meter. Converting that to our 6.4m tank(6.4m x 36.3m = 1167.8 cubic meters) gives 78.23 * 1167.8 = 91,357 liters and calculating for oxidizer: (91,357/0.9)*1,1 = 111,659 liters. This is a heavy tank(1030t if we keep dry weight at 15t), with just a Mk1-2 pod on top and mainsails underneath it gives us a TWR of 0.71, not really practical. (Same with the 5m and 3.75m versions, as they can only fit 1.25m engines(well, appart from the 5m version in the middle)).

TL;DR: Fuel is heavy, let me know how much you think should be in the tanks.

NOTE: You might need to strut your engines, as the size of this thing tends to play around with physics.

DOWNLOAD:

From Dropbox!

(Extract inside the GameData folder or if upgrading delete the HTP folder in GameData first).

Alternative KSP texture.

(Extract inside GameData folder, it'll overwrite GameData/HTP/K-V_S-IC-5/model000.mbm ).

(Between v0.3 and v0.4 the texture changed, so using the old one might give funny results).

(Not uploaded to spaceport due to the issues lately).

CHANGELOG:

v0.1 - Initial Release

v0.2 - Separated out the engine fairings as separate models and fixed the missing convex setting on the collision mesh(es).

v0.3 - Got rid of three engine fairings, just duplicated and rotated the last one. Changed the collision mesh to not extend below the base(ie ignoring the lip).

v0.4 - Redid texture/normalmap to make space for 108(bottom/center) and 216(top) stringers(the correct amount), CoMOffset -10m down on the 6.4m part.

LICENCE:

Free for personal use.

If you change the cfg and want to share your changes you are welcome to post modifications in this thread, if I like them I reserve the right to change the part cfg to match.

Do not include these part(s) in other packs or re-release without the creators permission.

-

Kolbjørn

(Feel free to let me know if I have managed to goof up something, it happens from time to time).

Edited by CoolBeer
Upgrades!
Link to comment
Share on other sites

Looking good, but in keeping with the spirit of KSP you might want to offer a texture without the stars and stripes and USA.

Otherwise it won't quite fit (aesthetically) with the stock parts, thereby severely limiting its value to many players.

Good idea, I actually have a KSP texture I can upload for it.

Are the flares at the bottom separate parts to overcome the need for a convex collider?

Dangit, seems like I zigged the convex thing! Time to separate the engine fairings out to separate parts...

(So it might be that collisions don't work as it's not marked as convex.)

Thanks for asking that question :)

I uhh, I've been UV island stacking, I hadn't heard anything about issues with that, is that only for normal maps?

I read somewhere that it was no-no to stack them, it was much preferred to have each and every part of the UV map separate.

It might have been this.

-

Kolbjørn

Link to comment
Share on other sites

Well I mean they can be separate .mu files with their own colliders and just call them using the MODEL{} call in the parent part.cfg rather than totally separate parts

Hrm, maybe I'll have to revisit my UV unwrapping, we'll see how it goes, hopefully not I was only just starting to get the hang of it ~_~

Link to comment
Share on other sites

Hrm, that's a good point, you could probably make separate node_collider meshes for each part (you want to have it's own convex collier), and just add multiple physics>mesh objects with Unity tools, I didn't really think about that, thought provoking

[Edit] best I can tell Unity Tools doesn't like multiple physics>mesh colliders within one gameobject part, it wouldn't let me anyway?

Edited by NoMrBond
Link to comment
Share on other sites

When I made a part like that, I made one big cylinder for the main collider (Using a mesh collider from unity, then removing its mesh rendered so its invis.

The cowls on the engines were separate objects in my hierarchy, and I added a mesh collider to them, but I did NOT check the "convex" button so they retain the original mesh shape. This allows them to be enabled for surface attaching and strutting, but they're pretty much ignored by the collision solver in game (which means they dont interact with the ground and such, so you might see the clipping once in a while, but it was a happy medium, and I was able to keep the main tank part a simple cylinder for maximum styability

Link to comment
Share on other sites

here is what I did with a part I made today: http://img443.imageshack.us/img443/3328/fg2c.png

The groups - game object, colliders, and ...generator - have no geometry. Game objects has the part tools as its sole component, and acts as a container for the entire part. Each item under colliders is a non-visible mesh who's only component is a convex mesh collider. Finally, the meshes under radioblablabla generator are what get rendered. So far the part has behaved for me nicely.

I only recently started modding, but I believe that many of the naming conventions have been greatly relaxed in recent updates, thus no need for a single "node collider" mesh; you get more freedom now.

Link to comment
Share on other sites

here is what I did with a part I made today: http://img443.imageshack.us/img443/3328/fg2c.png

The groups - game object, colliders, and ...generator - have no geometry. Game objects has the part tools as its sole component, and acts as a container for the entire part. Each item under colliders is a non-visible mesh who's only component is a convex mesh collider. Finally, the meshes under radioblablabla generator are what get rendered. So far the part has behaved for me nicely.

I only recently started modding, but I believe that many of the naming conventions have been greatly relaxed in recent updates, thus no need for a single "node collider" mesh; you get more freedom now.

That's pretty nice, I have to try that out tomorrow.

Thanks for sharing!

Looks really great. Are you planning on making the rest of the rocket?

I have started on the S-II and I'm scratching my head on how to do a proper S-IC -> S-II interstage, I would have to come up with a double action decoupler thingie, where I can drop off the S-IC first, wait a little bit, then drop off the interstage/decoupler. Any ideas on this would be super!

When I made a part like that, I made one big cylinder for the main collider (Using a mesh collider from unity, then removing its mesh rendered so its invis.

The cowls on the engines were separate objects in my hierarchy, and I added a mesh collider to them, but I did NOT check the "convex" button so they retain the original mesh shape. This allows them to be enabled for surface attaching and strutting, but they're pretty much ignored by the collision solver in game (which means they dont interact with the ground and such, so you might see the clipping once in a while, but it was a happy medium, and I was able to keep the main tank part a simple cylinder for maximum styability.

Yeah, I can totally see why you did it that way.

I wonder if this is a problem:

5NvGZPw.jpg

The outer engines will be intersecting with the collision mesh for the engine fairings, I tried making a version that ignored the lip below the base, but it didn't seem to make any difference(They were pushed quite a way into the main tank).

In game the outer engines seem to jump around some, I have attributed this to weak nodes and needing moar struts, but I'm wondering if this can be a collision mesh problem?

It seems fine strutted down though.

-

Kolbjørn

Link to comment
Share on other sites

Maybe.

The dancing is probably related to the mass difference between each individual engine and the overall mass of the tank part. Especially when you get up to the weight of fuel in that large of a tank, the physics engine gets somewhat imprecise on its calculations between colliders. Struts create a double joint and thus reduce the imprecision, which is why they help so much.

You can run a test by dropping the dry mass of the tank and loweing the fuel to just enough to fire the engines for a short test flight; it the wobble is vastly lessened then that was your issue; otherwise you might have some collider shape conflicts.

Link to comment
Share on other sites

Yes, it's a collision mesh problem. Ideally, the engine collider would fit snugly against the bottom of the stage. When it doesn't the node is the only thing holding the engine where it is, resulting in oscillations. Keep that in mind, especially on interstages.

Link to comment
Share on other sites

I did make v0.3 like this:

SsqfWBy.jpg

This didn't really change anything, the engines still jump around like they used to.

The problem is much reduced if using smaller engines(less thrust) or less fuel, so I suppose it's too much thrust/weight that is an issue. I haven't noticed the middle engine jumping around, but that could be center of thrust causing the outer engines to display more of an effect(is this even a thing?) or just me not paying attention enough. I have seen novapunch2 engines jumping around on a single point though, needing struts to behave, but that was generally with lots more thrust(5m parts).

Is it a problem if collision meshes of a welded object(multiple meshes) intersects? I mean, I wouldn't think so, but then again, who knows?

I did remove thee meshes though(three of the engine fairings), and just duplicated/rotated the last one to match, so at least I only have two meshes now.

-

Kolbjørn

Link to comment
Share on other sites

im glad some one is finally working on a decent model of the Saturn family of rockets, ive seen few others from before .21 that never really worked with the VAB we had then and with Tiberion's Nova(Slug)Punch 2 pack its possible to make a Kerbalized version, but a fully scaled Saturn would be a thing to behold given that with some .cfg changes the others work kinda in .21 but not all the way and are impossible to fly but actually fit in the VAB, although im wondering if, when this gets all filled out with the next 2-3 stages and an all up flight is possible if it will even fit in the much taller VAB we have now

Link to comment
Share on other sites

im glad some one is finally working on a decent model of the Saturn family of rockets, ive seen few others from before .21 that never really worked with the VAB we had then and with Tiberion's Nova(Slug)Punch 2 pack its possible to make a Kerbalized version, but a fully scaled Saturn would be a thing to behold given that with some .cfg changes the others work kinda in .21 but not all the way and are impossible to fly but actually fit in the VAB, although im wondering if, when this gets all filled out with the next 2-3 stages and an all up flight is possible if it will even fit in the much taller VAB we have now

The 0.64 scale version is just fitting inside the VAB as of now, you can push it up into the roof some, so maybe you could do a full scale one.

Launching is another matter, you would have to scale down the weight a lot, there is no way you'll get 2,800t off the ground without the physics engine having a stroke. You can take the same approach as the Apollo Mission Pack, where the first stage have a total of 2275kN thrust(455kN per engine), though their TWR is too high and their dV is off(note: I have only tested the released beta version, so ratios may not be final in any way).

My model is built as a 10m diameter one, so with a simple cfg edit you can see how it looks in the VAB.

Change the scale of the models to 1 and replace the nodes with:


node_stack_top = 0.0, 18.26, 0.0, 0.0, 1.0, 0.0, 2
node_stack_bottom01 = 0.0, -18.04, 0.0, 0.0, -1.0, 0.0, 2
node_stack_bottom02 = -4.4, -18.04, 0.0, 0.0, -1.0, 0.0, 2
node_stack_bottom03 = 4.4, -18.04, 0.0, 0.0, -1.0, 0.0, 2
node_stack_bottom04 = 0.0, -18.04, -4.4, 0.0, -1.0, 0.0, 2
node_stack_bottom05 = 0.0, -18.04, 4.4, 0.0, -1.0, 0.0, 2

-

Kolbjørn

Link to comment
Share on other sites

There is another thing you can try. it could be that the stage is so long, that the center of mass for the tank is too far "up" from the engines and causing the physics to be wobbly.

Try using a ComOffset in the tank config to bring the COM down towards the bottom.

CoMOffset = 0, -Y, 0

Where -Y is somewhat close to the "y" entry on your bottom node, so that the CoM for that part is close to the bottom node. You probably don't want the CoM all the way on the bottom like the node is, but moving it "down" from the center of the tank should help.

Now, this will mean that whatever is above the tank will have an even greater distance between the top node and the CoM, but sine the engines are applying thrust to the bottom its more important to have precise physics on that connection. You might have to strut the upper staage to the top of the tank, but that's just a reality of KSP and big parts.

Link to comment
Share on other sites

This is nice. Also, I'm already doing an Apollo mod with someone else, though he's done a bunk and I'd really like to get this done. I'm no good with unity/KSP but I'm a fair modeler. I've already modeled all the hi-res pieces for the entire Saturn V. I haven't went any further because I have no guarantee that the guy I'm working with will ever make a comeback.

I have started on the S-II and I'm scratching my head on how to do a proper S-IC -> S-II interstage, I would have to come up with a double action decoupler thingie, where I can drop off the S-IC first, wait a little bit, then drop off the interstage/decoupler. Any ideas on this would be super!

I fixed this easily on my mod by making the first stage a decoupler as well, then the interstage can decouple on its own.

Edited by Razorcane
Link to comment
Share on other sites

There is another thing you can try. it could be that the stage is so long, that the center of mass for the tank is too far "up" from the engines and causing the physics to be wobbly.

Try using a ComOffset in the tank config to bring the COM down towards the bottom.

CoMOffset = 0, -Y, 0

Where -Y is somewhat close to the "y" entry on your bottom node, so that the CoM for that part is close to the bottom node. You probably don't want the CoM all the way on the bottom like the node is, but moving it "down" from the center of the tank should help.

Now, this will mean that whatever is above the tank will have an even greater distance between the top node and the CoM, but sine the engines are applying thrust to the bottom its more important to have precise physics on that connection. You might have to strut the upper staage to the top of the tank, but that's just a reality of KSP and big parts.

Now we are getting somewhere!

I moved the CoM down 10m towards the bottom and tried both v0.2 and v0.3, both behaved pretty similar, which is very(very!) much improved(just a slight wobble). I tried upping the total weight of the tank to 206.67t(40t dry and 15,000l fuel / 18,334l ox), and there still was only a slight wobble in both versions(very much improved over normal).

So all in all it doesn't seem like the collision mesh is doing any more harm by intersecting with the engines(at least in this single case), I guess I could chop up the collision mesh in two, to get more a curve on it perhaps...

It'll be interesting how this will work out with the rest of the stack, especially when turning, the lawn dart principle will be hard at work. (Though most of the weight is in the first stage anyway, about 82% actually).

Thank you for this suggestion, your help has been awesome!

(Also, I'm stealing this trick for the command module, I want to steer through the atmosphere with a weighted pod(I tried to make this earlier by putting stuff on the pod, but it ended up back heavy, so it turned around and burned up my chutes... It was a bad day at work for Jeb)).

-

Kolbjørn

Link to comment
Share on other sites

What about sectioning arcs through the collider (assuming it already has a custom collision mesh?) for the central tank so that its collision mesh sits flush with the collision mesh for the flares (does not intersect), the bottom of the collision mesh for the tank would look octagonal becoming circular above the flares, as long as the cuts are flat it'd still be convex

Link to comment
Share on other sites

This thread is quite old. Please consider starting a new thread rather than reviving this one.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...