helldiver

Aye progress on this side. We hit a few easily solvable snags, ZRM got it under control (mostly to do with the landing gear). The good thing is every time we learn something new it just means that anything new we add would go in much faster. Anyhow continuing on with my mini-development insider... Step 2 -I then clone the master mesh into two meshes. -Mesh 1, will be the EFT Low resolution game mesh. I optimize it accordingly removing any geometry that won't be used. -Mesh 2, will be the EFT High resolution mesh which I will use to generate shadow, light, and normal map data. That is later translated into other textures such as specular and edge maps. Although often times some textures have to be done by hand. Step 2 A -The high resolution mesh is subdivided using the editable poly sub-division tools. This is where max 2010+ graphite modeling tools come in really handy (not shown in this shot). -If this was going to be sent to Z-Brush or Mudbox (which I use) I typically don't sub-divide as much but just enough to create a canvas to work on. For this project, since I'm not really dealing with anything organic (such as living characters) I don't really take it into mudbox and do all sub-division by hand in Max. -Note the completed high resolution version of the EFT. Step 2 B -The low resolution mesh is then given a single smoothing group by selecting all faces. -I then look at areas that benefit from their own smoothing group. I think some of you guys call this hard and soft edges. -I then apply a UVW map along the Y or X axis pretty much bathing the whole thing in one single UV. -I then select the faces I want to have their own UVW coordinates to create an "island". Basically any spot that can't easily be relaxed with the relaxing tools. I don't mess with it, max will do everything for me automatically. All I do is select the faces I want to have their own island, hit Unwrap UVW and then collapse. I do this over and over until I have all the pieces in their own island. For more complex meshes sometimes I'll hit it with a different material just to make sure I covered everything and didn't miss a spot. -After I am done I end up with a mess that looks like this: -That's ok, as long as all the areas I wanted to have their own islands are together, this mess is ok. -I then hit the relax tool along edges or faces until all those islands come together. -I then stitch as many of the pelts as I can to reduce the amount of seamlines visible on the final model. -I move my pelts to the best optimal location to save UV space. The big blank spot on the right is reserved for the Liquid SRB which we'll build later. The model is now done and ready for baking and texturing in photoshop.

I designed them to be compatible with anything really. I originally wasn't going to make engines, but then I realized I may need custom numbers on the engines to fit the needs of the KSO. Hence I put together the Thrustmax and Omnimax. I don't have max fired up right now, but the KSO is 1.8m wide to the edges, so judge it based on that. Which would mean much much smaller than 1.25m. In my write up the OMS engines were designed to perform poorly at atmospheres but much better in a vacuum.

Alright, here's a quick project update. -Technical work continues on the KSO portion. So far things have been good and ZRM got it in game more or less. There are still a few bugs to flesh out but all that should soon be out of the way. -We're not posting any in-game pics until the KSO is properly in game and all bugs are sorted out. Currently not all textures are on as well as there is still quite a bit to get functional (such as the IVA, landing gear, etc). -Unfortunately do to the design, its use as a parts pack is severely limited, more so than we originally anticipated. This being temporary or permanent is up in the air. A lot of it has to do with buggy attachment node code. -The good news is that the cargo bay is working superbly. ZRM even did an EVA walk around with little to no collision errors or problems. -As a heads up, the shuttle works magnificently with the KCA mod. As I said earlier for the first versions of it, I'm not providing support for a non-KCA version of it. That doesn't mean you have to have ZRM's KCA mod, it just means that there is a possibility that the KSO will be very unstable without it. For the average user it will be a required download. We are currently not spending time on engineering a version without KCA. Later on once we have more of the project fleshed out and folks are flying it, we can go back and release a non KCA dependent version for advanced users. Since it seemed that ZRM didn't need anymore direct art support for this first phase, I decided to move along with other parts of the project, in particular the lift vehicle. -The EFT will not be segmented, heads up because I know we'll get a bunch of folks asking. There are plenty of segmented fuel tanks both in game and on the space port. I'm not making one. -The EFT will be designed to go with the KSO (see WIP pics below). That means you're free to try to use it on other assemblies but its attachment points and configuration will assume the KSO. -The Liquid fuel boosters will be liquid fuel. They will be solid as well minus the engine. -Like the boosters, the EFT has an engine mounting location on the bottom. -Parachutes, sepatrons, and accessories may be integrated into the EFT and Boosters. I don't know at this point. This means you won't be attaching the stock parachutes and sepatrons by default since those components will already have them. For those of you that wanted some texturing and modeling tips I'll do my best to post pics of the process, starting with Step 1. Step 1 -Using 3D Studio Max, I create the Master model of the External Fuel Tank. This model has more polygons than the low resolution model used in game, but less polygons than its high resolution version I'll use for map generation. -I make a clone of the KSO that I weld as a single model. This will guide me in figuring out the scale and size of both the EFT and the external boosters. -I use the real space shuttle EFT as a guide for my own stylized KSO EFT. -I primarily work in Editable Poly. This allows me to extrude edges, chamfer, sub-divide, collapse as needed. Although I started with a basic cylinder which I collapsed down to Editable Poly. Completed master model:

Going to clarify it up a bit more since the other day I got PMed again and I didn't explain thoroughly. Honestly, I don't use any "tools" perse. Aside from the standard editing tools you find in photoshop, Google (to search for textures) and generous as well as proper use of high resolution texture generation. There just isn't a magic tool or set of tools that can do it all for you, it really is a process or workflow you'd have to learn. There are some awesome tutorials out there by Ben Mathis, as well as the Polycount forums which I've been a member for years. Lots of industry professionals there give many tips and you'll find all sorts of tutorials covering map generation, workflow, understanding topologies (to make subdivision easier) and so on. It would be impossible for me to give folks a straight answer without an hour long tutorial. I usually start with a master model. The master model rarely gets into the game. This model is sub divided in a way that has as few poles as possible. This makes it easier to sub divide the model upwards (for high res version) and downward for the low polygon game asset. Mudbox and other sculpting tools (such as Zbrush) hate models with too many poles, so understanding edge loops and topology is kind of important. The reason I say that is because it's all linked. As a very skilled artist once said; the days of making a 3D model and then slapping a texture on to it later on is pretty much over. The 3D model -and- the texture is kind of done together in a way. It's not uncommon for me to make two separate models completely. For the KSO, I believe I made a total of about two copies of it from scratch... I know for sure I made like three different wings and two cargo bays. This was because the low res wouldn't subdivide properly into the high res, requiring that I construct essentially a new model from scratch. Unfortunately the second model wouldn't cast properly without a lot of projection errors so I had to rebuild them again. This normally doesn't happen on characters since they are usually a single piece. But for the KSO since it was a bunch of parts, you have to do so much more work. Although had I known what I know now about attachment nodes, the KSO would have been done in about half the time. -All of the high resolution components of the KSO. Every screenshot I've shown you guys, those objects have a high resolution component. Even the flat windows have a high resolution counterpart. -From 1 million polygons, down to just 12,000 -The high resolution mesh of the cockpit. Once you have your high res and low res UVed, you then use one of several tools (it depends on your 3D modeling program) to spit out a texture island map. This helps you in photoshop to figure out where everything is and where the edges of everything is at. When UVing you want to relax all surfaces and islands as well as kill as many seams as possible. You then want to get all islands in proper locations to save and use as much of the UV space as possible the most efficient. Understanding how UVs work is very important and it can take some practice. I sometimes will make certain islands larger than others if I want more detail in those areas. In the image above you'll notice that the Ambient Occlusion map was used as the primary shadower throughout the diffuse. I play around with the brightness and contrast values as well as hues until I'm happy with it. I typically set it to a greyish brown hue since video cards do not like true 0,0,0 black. Once that is set I start texturing. Either painting them by hand or using textures from my library or online. I bake more textures such as the normal map so that I can use them to push light values, get detail, or blend an area in with its geometry (such as folds on clothes). A normal map can also be used to generate your edges, although do to how complicated the KSO was, I had to do most of that by hand. Since the outside of the orbiter was going to be kept plain and not too weathered, I did most of the edge work in the interior. -The cockpit interior with its edge map turned to 100% -Edge maps are screened into your diffuse -and- your specular to push edge highlights out. Edge maps along with Ambien Occlusion are crucially important. Because the KSO wasn't going for a realistic look I didn't do a color map. However a color map, or a color diffuser layer on your diffuse is really important in breaking up your colors (in real life light scatters and nothing is perfectly white, or grey, or any one color). However a color diffuser (or scatterer) typically goes better with a dirt and grit layer. Again, the clean look of KSP just wouldn't work well with such layers. In conclusion there is no simple step or tool that I use. Instead I use a process that I've been trying my best to perfect over the years. -Master model with proper edge loops and topology -High Resolution model with as many details as you want. -Low Resolution model -Unwrapping UVW and relaxing your islands along Face or Edges. -Moving mirrored UVs off by a tile offset -Generating a UVW Island map to be used in photoshop -Generating a Normal Map, Ambient Occlusion, and any other map necessary. Using the maps you generated to help you put together your diffuse map and specular.

Oh! yeah yeah, radiators on the cargo bay. Way back when, the KSO had them, I removed them because they just weren't aesthetically pleasing no mater what shade I made them. So I stayed with the stringer detail keeping with the pseudo industrial KSP look. I'm not sure what you mean by tools? I use 3D Studio Max, Mudbox and Photoshop. In max: -Render to texture to bake high resolution geometry into the low resolution UV. There are a myriad tools to do this with including some like xnormal where it can take your high res and low res and generate a normal for you without having to deal with a projection cage. I prefer the old fashion way using a projection cage. UVW Unwrap and relax tools (either by Edge or Face depending). -Texporter to know where my islands are. In Mudbox: -A good Wacom tablet. Photoshop -I then use my ambient occlusion bakes, normal map trickery (such as edge projection), the grey channel on my normal map, to do all sorts of tricks. -My trusty Wacom tablet.

Octagonal even... my brain was thinking six sided for some reason

Correct, I like the module idea more than replacing the cargo bay with a passenger segment. I'm confused by what you mean by the interior of the doors? Do you mean the inside texture or? The colors, texture, and 3d shapes based on a lot of factors influenced by the model itself. The exterior of the modules would probably be hexagonal kind of like the docking module. The pieces would follow more or less that design aesthetic, except obviously longer. Probably fully octagonal and not asymmetric like that one is. With details around it (cabling, batteries, details). All modules would have emissives to aid in docking and prevent crashing into the thing at full darkness. I'd use emissives for lights instead of real lights as that would be significantly less intensive (and you'd have zero parts involved). The interior would follow me signature beige accented interior with white/grey lab stations and details. Again all of that stuff is on hold until we're successfully flying the KSO.

I would -love- to do a space station "set" all compatible with the KSO. Actually, I always had planned to eventually do that, since judging from the original pics of the orbiter I saw (the one I posted on the OP) most of the space station parts wouldn't fit inside it. The set would consist of a series of modules that all fit inside the KSO. They be designed with: -Gameplay and fun being #1. This would only come with the support of advanced modders such as ZRM and the others that have helped me in this thread, and from the devs. -Easy of use. I'd rather be called a "cheat maker" than make random stuff that's a nightmare to deal with. For example, the moon lander that I plan to make for the KSO will have a lot of things already integrated into it. This makes loading and releasing it from the KSO simple and seamless. The vehicle itself would consist of a minimum amount of parts and would be designed with simplicity and modularity in mind. The mini rover vehicle would be designed to fit the lander while at the same time have ramps that clear its engines. The mini-rover would all be a solid vehicle with slots to attach instruments and batteries. One reason why if I designed an arm, I'd want it to work centerline with the floor of the bay and push items outwards (or grab and pull them in). That would allow you to use the KSO to plot a coarse to a planet, release a probe/rover/lab component, and easily be able to retrieve it. I like your idea. I'm against the idea of a cargo bay replacement "passenger cabin". I entertained the idea for a bit, but then realized that it just didn't make sense at all. Why would the Kerbals spend millions doing all the research, wind tunnel testing, building the orbiters, to then slice the thing up and install a passenger cabin airliner style? From a scientific purpose perspective it just didn't make sense to me. I'd rather build a space station component, lets call it "habitat" that you load into the cargo bay. You could have say six or more kerbals in it. We could then make a whole bunch of variants of that module. A crew version, a lab version, a power version, optical bay (for photography), an astrometric research version, etc. Keep in mind that the KSO cockpit segment will eventually allow more than 4. Eventually I hope to increase that to 6 by opening up the mission deck below the flight deck. -Note the hatch just below the starboard emergency exit hatch If I did a lab I'd really want to detail it inside. It would be marvelous if I could get someone with a lot of knowledge regarding KSP. I can animate kerbals actually working on experiments. So anytime you move kerbals to that segment and do research, if you hit IVA you'd see them floating over to the different laboratory experiments and work on their projects.

In regards to KSP, what would be the gameplay function of a space lab? I would rather spend the time making space station modules that fit the cargo bay of the KSO. You could use those modules as a space lab I'd imagine. In regards to no updates, the project is no longer in my hands and is currently being processed into KSP. Unfortunately we've run into a few technical snags related to the Unity --> KSP process. Once all that is cleared up we'll begin the primary testing phase. During which I'll be fixing any art related issues and completing some of the artwork assets that didn't make it into the first phase such as emissives for the KSO to facilitate docking and other minor details.

I'm planning on several additions to the KSO. -Lift vehicle -Mini lunar lander consisting of a command pod, fuel section, rover container. -Mini rover vehicle. -I'm planning a robotic arm, but it won't work like the Canada arm of the real shuttles. Instead it will be more like a jack that facilitates release of the cargo you load on it. The arm itself would be on the floor of the cargo bay and lift/push cargo outwards.

I'll leave it up to you regarding dummy_attach_cargo_gear_left(right). They are both on a kingpin vertex that is shared with the wings and the main gear. Simply unlink it from cargo_bay and link it to their respective wing. The only thing I would do different is rename from dummy_attach_cargo_gear_left(right) to dummy_attach_right_wing_gear and dummy_attach_left_wing_gear respectively (unless you're using your own naming convention). Either way, let me know via PM if you reassign those attach points so I can do the same on the production files. However, realistically the gear would be attached to the main root spar. In an event of a crash the wings are designed to rip off leaving the gear as intact as possible. So technically, the gear should actually stay on if the player were to rip the wings off since they are traditionally attached to the strongest point of the entire aircraft. Actually, believe it or not, on most real aircraft (dunno about the shuttle) that area has the most expensive and difficult to manufacture structural component, the primary former. In many aircraft it is made of a solid machined titanium slab. The attach points in the cargo bay and engine mounting (on rear_end) are the minimum required. The reason why the mounting pads have two (01,02 and 04,05) are so that you can mount larger than off-center items on them. However, if you find 02 and 05 to be too close and unnecessary feel free to remove them. If you move any of the attach points on the firewall, the engines won't line up with the baked mounting location on the texture. If you think attach_rear_rear is too close to eng_01, feel free to remove it. However that attach point gives players a centerline location for mounting the shuttle symmetrically on top of a fuel tank. Rear_end attach points rudder_01, 02, and 03 are to give players the option of a v-tail or standard rudder. I think everything should have been spaced out appropriately. Let me know if you plan on removing or moving them particularly any that involve changing the form factor of the final assembled KSO.

Alright, does it matter how many attachment nodes are on a part? For example, cargo bay right now has 7 cargo pad attach points plus its front and rear attach points. We then have the two for the wings. So I'm wondering if I should have the gear attach to the cargo bay or the wings?

Do more attachment nodes make connections stronger? Like say I placed four in between two segments?

Images go with Guide.doc, also to help discuss and get insight from the other experienced engineers. -Note vector location. This is so the player can set up an action group to increase the angle by 5 or 10 degrees or however you want. -Note gimbal location. Player doesn't have control on this. As you know KSP/Avionics, etc governs this. -Note RCS vector direction, just in case I fudged them feel free to rotate accordingly.

I may in the future (and that's a big may) do art packs such as landing gear. You'd then take those (FBX and TGA format) and implement them into KSP. They would be generic and compatible with any mod. Again it's a big maybe and all depends on my schedule and if there is enough demand and appreciation for that sort of thing.

-No they come out from the body. We don't have to animate them coming out. I just concerned about the RCS gas effect emanating from inside when it should emanate from the nozzle location. Remember that the lower nozzles pop-out slightly from the body (unlike the others) see? See how they pop-out? -I won't do the RCS then, you can place them in Unity like you mentioned. -Ok no problem with the body plane. -Nevermind, I just realized you'll probably just place the RCS tangent object outside the nozzles and not have to fuss with them moving in and out when the player pops them out. -Wheel wells -Docking bay module -Cockpit windows -Fix the throttle collision so it's not concave. Ok I think that should cover it all. Engines, do the engines need anything or is that all done in Unity?

Ok fantastic! You guys have been an invaluable help to this project, thank you so much!

Alright coming in to the finish line here, got about two more days from my end. You guys got to give ZRM a minimum of a week to two weeks at a minimum. Just because I'm finishing doesn't mean the project is ready yet, in fact as we've just found out the problems have just begun. Collisions semi-final: -Note that they are flush to each other, all vertices snap both to component collisions and to adjacent part vertices (as well as visual model) -How I solved the cargo bay. Keep in mind it's not finished as I'm still awaiting feedback on whether we need extra vertices for surface attachments or not. Sadly it had to be 7 parts in order to properly cage the visual and be flush without intrusions. -All cargo bay pieces as well as other collisions I made them so that they were flush with each other. Note how the wing collision matches the former I made on the cargobay collision pieces (highlighted green). The wing collision does not intrude into the cargo bay. -Super imposed over the visual -The rudder visual is slightly offset to its collision so that the rudder looks like it's part of the shuttle and not floating. -The RCS components are just visual on the bottom. The RCS tangent will be linked to the movable nozzle on the bottom, no need for collision meshes for that. -Does the body plane (the black elevator looking thing behind the firewall) does that need a collision mesh also? -I didn't do the landing gear collisions. Did we need a box around the landing gear boxes? -I didn't do the docking module, does that need a collision mesh also I'm assuming? -The rear end collision also has extra vertices where the engine attachment points are. Did we need those or are those implemented with attachment nodes? -Should I do the RCS tangents or is that easier in Unity?

@ZRM and other engineers. -Notice the vertices I highlighted in red. You want those? Or are you going to put attach nodes instead? This is for mounting stuff inside the cargo bay. Otherwise I'll remove them and the collision mesh won't have as many faces. -Box dummies (in red) are driving the animations right now. Ok to keep those? Or do want me to collapse them into the actual meshes they are animating? The advantage of course is you'll have less stuff in the hierarchy you're flagging is non-renderable. The disadvantage is that if I make any changes, I might have to reanimate the part or I could fudge the transform. -And finally, you want one big huge FBX with everything in a hierarchy? Or individual part fbx's?

Ok ok, that's what I needed. Darn we lost a day. It's ok, I'll try and get it all done over the weekend.

Ok now I'm lost. The problem at this point is I don't know what to model or how. -I'm assuming by surface you mean the Rudder and anything players put inside the cargo hold, correct? By surface you don't mean the wings, fuselage segments, etcetera right? -You said that the elevon doesn't need a collider. So I'm assuming it'll animate and properly control the aircraft in game correct? Using red or a clear color, please draw an overlay of what the collision cage(mesh) should look like. and the cargo bay Project is on hold at the moment until I can get that information. We may have to move the project to Skype so I can put the mesh together in real time while one of you guys coaches me the collision meshes' edge flow. It would save a ton of time.

Alright, so this should work in theory right? (I forgot that the cargo bay had to be hollow inside so that you could load it with stuff.) Note that in-game the wing's collider would intrude into the cargo bay collider. I'm trying my best to not have to double up on work, or keep errors to a minimum.

Alright, no problem. As long as the parts snap flush without gaps or visual errors. Ok so the cockpit segment can be one solid box (or slightly molded box) with the landing gear another box, and it can be inside it right? So for the wings to cargo bay, we can have a box eventhough when you assemble the vehicle those boxes might end up inside the cargo bay collider box?

Alright, I understand the whole thing now. One last issue, it seems my get vector tool isn't the same as the one the KSP guys used. Anyone have a link to the one they are using which spits out a KSP CFG format? I don't have KSP Cfg format in mine. Or maybe it doesn't matter and it's just a matter of moving the decimal over.

It seems that the ladder colliders have to have their axis a certain way. Can you flag the ladder collider to not be visible? If we can't then I can texture it 100% transparent using our Glass_pane texture channel. That way I don't have to reanimate the visual ladder and I can keep things much simpler.