noonespecial

Sometimes when importing/export DDS files, they get flipped. Try flipping your edited image and see if that fixes the problem.

Progress! Atmospheric Lander (Inspired by the Boeing Mars Lander)

There is always Progress. Marriage Equality in the U.S. progressed recently. I just read an article about the progress of fusion energy research. Oh wait... you probably mean this mod. Yes, progress is being made. But, as you probably know, I also provide models for other mods, such as ChakaMonkey. As they are already released mods and mine is still in progress, they take priority in my mind. KSP 1.1, then 1.1.1, then 1.1.2 has been breaking things left and right. So I've been fixing things

Nah, only the Orion has had so many revisions. That bugger is deceptively complex. It would take me less time to model the core of the entire SLS rocket than it would take to model the orion and service module. But, just to clarify, the core of SLS is done, I'm just waiting for KSP 1.1 before release (man... is that release dragging and dragging and dragging). When I said I was getting ready to dive into some serious modeling, I was referring to the SLS payloads (the landers and various satellites). Hopefully this clears things up

I have no idea. I'm one of the unlucky few who didn't buy KSP through Steam. I'm just as curious to see the graphic capabilities as everyone else

Unfortunately, KSP won't be including the standard shader in 1.1 due to performance issues. They will be using their current shader. (That is, unless of course, I've missed an update in the devnotes since they announced they won't be including the Standard Shader). Of course, you could alternately use the Reflection Plugin or WindowShine.

Unfortunately, no real progress on the payloads. I took a (long) break from working on SLS to level up my modeling skills before diving back into again. As you probably know, before deciding to do the SLS mod, I had never really done any modeling before. To say the least, I was an extreme noob. As can be seen here with my first version of the Orion and Service module: As compared to my most recent version: https://sketchfab.com/models/08b99891e34a4399816dfb2e88e7e89e Even that one is a couple of months old. Since then, I've really been diving into modeling as a serious hobby. My most recent work has been completely unrelated to KSP or SLS, but I think my modeling is starting to actually reach a level that an SLS mod deserves. Here is one of my more recent projects to show the difference: But, the short answer is... I'm getting ready to rebuild the SLS from scratch with the high quality models and textures that it deserves. I'm afraid if I had released it earlier, it would not have been a very good mod and I'm afraid that I'm a bit of a perfectionist

Nope. I bought KSP through the Squad Store, I'm not on steam.

I have a suspicion that is not related to the docking port (or at least, isn't ONLY related to the docking port). While testing a few things last night, I had this same bug happen.... but there wasn't a docking port on the ship and it wasn't during a docking/undocking procedure. It happened during atmospheric re-entry. The parachute module blew off completely during re-entry and got locked at a distance from the ship. Luckily, the parachute still deployed and safely landed the ship... despite being who knows where (below the ship and below the ground at that point)

There are 6 parts in that Sketchfab and 6 textures. The LES, the Aeroshield, orion parachute module, the orion mpcv, the orion heatshield, and the service module. There are four meshes in the parachute module (the base, the cover, and two parachutes [drogue and parachute]). There rest are single meshes.

I'll just leave this here... for some reason. https://skfb.ly/LBEW

Write down the details of what you don't want, then go through the mod's folder in GameData and find the parts you don't want and just delete them. If you are careful, you shouldn't break the entire mod

We are aware of the problem. The most recent update to KSP made the old Altair nonfunctional, so it was remade from scratch. It still has some bugs to be worked out. Unfortunately, the Altair is on the back burner as we are putting the priority on finishing the new Orion. The docking bug with the Orion is also known (read about it in just a few posts above yours). We are doing our best to work out these bugs as soon as possible.

Use the alternate download sites of CurseForge or Dropbox. They are in the first post directly below the KerbalStuff link.

I'm hoping. I'm hoping we get an updated version of PartTools soon too. Though I'm super bummed by the news that 1.1 will not include the PBR shaders (so no real time reflections and realistic materials)

So the Monkey Action Tickets are up to F-CK001-D? Man, the NOS Action Tickets are up to F-CK666 by now. Rather discouraging.

The one thing that burns me out and discourages me the most about modding for KSP is the apparent disconnect between Unity and KSP. This has been a problem that I've been encountering since I've started modding for KSP. For example, currently I'm doing the parachutes for the Orion. I've been doing the parachutes for the Orion for about a week. Process is like this: Made models in blender. Perfect. Import models into Unity. Perfect. Do Parachute animations in Unity. They work flawlessly. Pump it though PartTools into KSP. Parachutes deploy in the wrong direction. Double check animations in Unity, export. Same result. Look up problem on the forums. Try solutions. No change. Go back into blender, rotate and apply rotation to make the model "Y-up". Correct in Unity, redo animations. Export to KSP. Same problem. Rotate parachute in KSP, redo animations, export. Same problem. So I'm currently redoing the parachute hierarchy and animation for the dozenth or more time. Same problem. This wouldn't be so bad if this were an isolated incident. But seems like every single time I try to do anything that requires animations, it takes a week+ to figure out the problem. Each time, it's some wonky solution that is at best a workaround because of some broken disconnected between KSP and Unity. :angry and frustrated:

At best, you could use duplication for high poly modeling on your models for baking out AO/Normal maps, which would improve the overall quality of your in game models. This was simply experimentation to see what could be done and how in KSP. While one could use these techniques to get a working high poly model in KSP, I wouldn't recommend it.

@landeTLS Thanks for the info! Sorry, I didn't mean to give the impression that I ignored your initial post. You said you were too sleepy to respond properly, so I was expecting you to come back and respond more fully. So I was waiting until that to respond. Now that I think about it, I would cringe as well with that usage of geometry if someone were attempting to put that directly in KSP. I would assume that a person who knew enough about Blender to pull off the duplication would also know enough to use them to bake normal maps to apply to a lower poly model And again, thanks for the information. Very enlightening.

As far as Unity handling it natively. I do believe you're right. I habitually export to FBX instead of importing the blend file directly into Unity, so I didn't notice initially. Unity gave me a "cannot convert to FBX error". However, using the cube example from above, exporting the all unique assets 3.5 trillion poly model resulting in a 140m file that Unity chocked on, even in FBX format. The duplifaces model exported out to less than 1mb and Unity imported it without issue. If I understand it correctly (not guaranteeing that I do ), Unity considers the duplifaces are instances of a Prefab, with the original component being the Prefab within the model. Basically, the parent object is just telling Unity where to place the Prefabs. My main concern, however, isn't what is happening within Unity, but what is happening within KSP. Unity handled the file without trouble, displayed it correctly, and ran without lag. Once exported through PartTools, the file ballooned to just over 400m. So is it beneficial to use? I think in some cases, it could be a useful time saver, such as the bolts on the Orion above (or if you want to make an insanely highpoly model that Unity chokes on).

Yup. All the duplicated objects are copies of the original asset, sharing geometry, uv, etc. You would have to export the the parent and all child objects. Otherwise, the parent wouldn't know what to instance in the game engine.

A better example of how to control it and use in KSP: So let's the ole Orion here. Let's say I want to put a row of bolts going down the side. So let's create a plane and a bolt object. Remember, Two different objects sharing the same origin. Then I'll go into Edit mode of the plane and create another face going down the side of the Orion. Parent the bolt to the plane and duplication... So now you have a nut on the side of the Orion. Meh, not very useful. But, since Duplication Faces relies on the face count of the object. Let's Loop Cut that face. 19 cuts sounds like a good number.

With duplication faces in Blender, you need two objects. It is easier to work with if both objects share the same origin. In this case, I want to use the plane to duplicate Suzanne, so I'll parent Suzanne to the plane. Then, lets go into Edit mode of the Plane and create a few more faces. Where you put the additional faces will be where Suzanne will be instanced to. Under the Object tab in properties, under the Duplication section, select faces. And... presto You can also use the planes to control orientation of the instance: When it is rendered, or displayed by a game engine, the faces of the plane are not displayed, only the parented object. You can also parent multiple objects.

I wasn't surprised by the results of the 3.5 million either. The final mesh had 5,980 triangles, between the honeycomb segment (3,520) and the parent cube (2,460). The game engine then creates instances of the honeycomb and spreads it across each face of the cube. In the original, the computer/game engine has to calculate and render each vertex. In the second, it only calculates and renders the much smaller honeycomb segment, then copies it onto the rest of the parent cube. It is more expensive to render in realtime than just 6,000 tris, but significantly less than 3.5 million Although, I'm more interested in seeing it applied to something like this There are 70 identical 12 sided bars supporting the structure of this lander. I had to skip a lot of details due to already running pretty high on polys after just being the frame. It would free up nearly 2,000 triangles worth of details by "instancing" out all the duplicate bars instead of creating unique mesh duplicates. I'd be interested to see if there is a performance difference between those two models.

Well, it's rather difficult to tell from your photos, as we can't see the seams on the model or know which part of the model equals which island in the UV. Did you create seams for the windows, or are they unwrapping as part of the total mesh?