noonespecial

Check the error log and see if there are any errors during the time of frame rate drop.

Excellent, thank you all. As many of you observed, I wasn't referring to these models, but general best practices and pros and cons of each. Might be no real difference in models like this, but when you're pushing thousands of triangles... So from your comments, it would appear that the middle object (green) would be the best practice. It has the highest triangle count, but as you pointed out, triangles are cheap. It would also maximize UV space and require the fewest draw calls. Is that an accurate assessment?

A simple theoretical question I was thinking about earlier. Here are three models that are visually identical, though geometrically different. Yellow: Two meshes, one pass through the geometry of the other. 24 Tris. Green: Single mesh, inset and extruded. 44 Tris. Blue: Three meshes, aligned face to face. 32 Tris. When rendered (AO shader), they are visually identical. The question: As far as KSP is concerned, are there any pros or cons to any of these practices or generally speaking, is one practice better than the other two? Or... is there even a difference at all?

You forgot the rest of it: "Another probe, but smaller than the Europa Clipper. But then again, it is just an orbiter. (Please, no tissue paper jokes)"

TweakScale is but one option. A MM config could be written to autodetect RSS and/or RF and add the required support automatically. That's another option (though, one I don't know how to do yet) No worries mate

Update December 8th 2014 Almost finished with the base Orion model. Textureless at this point.

I think there is a big misunderstanding / miscommunication going on here. One of the reasons you think my logic is flawed is because of this. I'm not sure if I've phrased my intention incorrectly or if there have been certain assumptions made. To correct the misunderstanding, I will flatly say again: I am providing 0.64 scaling AND 1:1 scaling. As in, both. The logic is not flawed, because you're applying it to the wrong side of the "and". So to reiterate once again: I am providing both 0.64 scaling and 1.0 scaling. Soo, we cool?

Hmmm. I don't often use procedural fairings, so I haven't encountered that bug. Good to know

I've never actually had a problem building oversized rockets. It's easy enough to shift-click to select the entire rocket and move it up and down while building, dragging it up past the editable area or the down into the floor as needed. But also to clarify one very important distinction here. This mod is not meant to be exclusively a historical replica, it's also designed to be a general parts addon. P.S. Is historical replica the correct term? because the SLS hasn't actually been made yet

No flaw in logic. I'm modeling at 1:1 because that is my choice and preference. I will include tweakscale (I stated this earlier) for those who wish .64. As far as this scaling only being useful for RSS, that is quite frankly untrue. As far as the game engine is concerned, a cylinder with 14 faces and 44 triangles will always be 14 faces and 44 triangles regardless if there is some arbitrary configuration file saying it's 8m or 5m.

Like I said, if someone wants .64 scale (aka 5m parts), then there are already loads of mods offering those. KW Rocketry, ChakaMonkey, NovaPunch, among others. I'm not a big fan of re-inventing the wheel. There used to be people that said, "OMG! Why 3.75? The whole game is geared toward 1.25 and 2.5!". Then there was stock 3.75m parts. Then people said, "OMG! Why 5m? The whole game is....". Then there were 5m parts. And there are still people using ridiculous and unrealisitic rocket configurations to lift heavy loads. So why not have 8m parts?

My reasoning is simple. There are already LOADS of mods with 3.75 and 5 rocket parts. So why make another? Plus, as Budgie mentioned, if someone HAS to have a .64 scale version, I will be including tweakscale to accommadate this. But, it will be the lower stages will be 8m, the upper stages 5m and so on.

Approx. 8m

Originally, it was just a stroke of inspiration while I was making the texture. Then, an idea came up about making a plugin to have paint "wear" during re-entry and/or aging. So the white texture would be the usual normal texture and the dirt texture would be the worn one.... if, I can figure out how to make the plugin or if someone like Stupid_Chris makes it before me. Otherwise, it'll just be the normal white texture. Hehe. Maybe! More than likely, much bigger. You'll probably see it released at that size in another mod, but part of my SLS mod, it will be more like 5m base.

Updated the texture (again) Next: clean up the normals around the window and forward rcs ports. See if I can make the smooth edges smooth and the clean edges clean.

And "tiles" done (I think). I like them anyway. As far as the black look, I actually prefer the white from the concept art and early construction than the black tiles from the more recent construction shots.

I have a little (read: very little) experience with C#, I'm more familiar C++. I'm not familiar with the KSP/Unity APIs though. I'll have to look them up. I've glanced at them a few times here on the forum. I'll see if I can figure out, if not, I'll ask some questions. Good luck with your finals

Er.... um.... easy you say? I have no idea how to write a plugin, but I guess I'll look into it.

Keep in mind that is a WIP base texture and not the finished product. It is still very rough. But, here is the progress on the texture, with three alternate textures I'm playing with.

YANFRET and I were talking recently, discussing texture I've made for my new Orion MPCV pod and YANFRET had an idea. I have two textures for the pod: and The idea is simple. To be able to animate the texture so that the later texture is showing after re-entry. Since we're using DRE, which has heat shielding as a depleteable resource, perhaps the animation could be bound to the usage of resource. Or... something else. Neither of us are programmers, so we're only guessing. Would anyone care to take a shot at righting a plugin to accomplish this?

Here is the low poly model (3.1k) with normals and base texture. I need to clean up the normals and refine the texture with more details and such. But here is the prototype. Opinions?

Update Now that my computer is restored, I'm really feeling this mod again. Here is the high poly (around 400k) of the Orion MPCV I'm working on (textureless ATM). It is what I'll be using to bake the normal maps from after I finish adding all the detail work. The low poly model is much more manageable at around. I'm having to manually retopo this, but I'm estimating that the final poly count will be around 4 to 5k. Enjoy

Update November 29 2014 Good news is, I've rebuilt my crashed computer and pretty much up and running again. I have completed two of the payloads to my satisfaction and will be starting on a few more soon. The Mars lander and accompanying command pod are completed. I will be putting the finishing touches to the inflatable habitat portion of the Mars landing system (luckily, was able to recover most of it) soon. Then, I will be starting on the CISLUNAR, the ATLAST, and the Lunar Surface module. I hope to have them completed before Christmas. Assorted Eyecandy

I'm not quite at the stage in development where I'm making fairings currently. If I choose to make static fairings, as opposed to procedural fairings, I will make them within the specifications of those used by the real SLS.

Thanks wasmic! first draft of the orion? You mean this monstrosity?