-
Posts
455 -
Joined
-
Last visited
Content Type
Profiles
Forums
Developer Articles
KSP2 Release Notes
Everything posted by InsaneDruid
-
Thanks Mate! Of course this will be fixed!
-
http://blender.stackexchange.com/questions/5283/how-to-show-textures-in-the-3d-view-editor Also make sure that, in the Properties panel, under the Object tab, in the Display Section, Maximum Draw Type is set to Textured. PS: personally, I always work under cycles, as I find the material nodes so much easier to work with than the blender internal way.
-
No need to apologize! Problem are many false sources. Even wiki shows this infamous image https://en.wikipedia.org/wiki/VA_spacecraft#/media/File:TKS_cutaway.png and this is then often used to model a tks (like shown here: http://farm7.static.flickr.com/6211/6312866521_9d50376bae_b.jpg resulting in completely wrong dimensions, false and missing tapers, completely false inner config (as it shows a later variant fgb without the rear cockpit) - even the sources states "Details are conjectural".
- 22,660 replies
-
- 3
-
-
- totm march 2020
- mod
-
(and 2 more)
Tagged with:
-
Wrong. They all are "cylinder-hugging", just with different mechanisms. "Ye olde" TKS (like the Kvant tug) had panels that where built from panels shaped like ˆ and ˇ : and thus never folder flat, like early Soyuz. See this image: (from a Soyuz) And here on Kvant-1 (you can also see the fairing nose cone) the hinges where on the top and bottom side as seen in this image (like on the front and back on the craft when erected on the pad) Here on a later unmanned Almaz-T radar "satellite" (an unmanned Almaz station with huge side looking "sword" radar antennas) the later designs folded much more complicated in a way also used on the yet to be launched Nauka: but they still "hug" the cylinder: in this design, there is a central frame elements with hinges on the front and back (as located in the image above), thus like on top and bottom when the vehicle is erected. On this elements the actual panels are attached with hinged on the top and bottom (as as located in the image above) (like on the front and back on the craft when erected on the pad). It should be clear from the images. This way, the actual panels could be feature another fold. Like so: Hinges are the Red, Green and Purple lines. Imagine this panel setup fold from open to close (reverse from the actual opening sequence)., First fold the extension panels along the purple lines 180° back to back with the main panels. Then Fold the center structures along the red hinges 180°, and then fold along the green lines about some degrees to hug the cylindrical spacecraft. You can see this setup uses on main panels of the main module of Mir: (but the later added third one uses a scissor mechanic) and also on Zarya (but in this images, only the "red" hinges are folded partially. I have coloured the hinged according to my drawing from above: Here is an image showing the unfolding sequence of such an array: EDIT: the only "flat" panels where on some of the early Almaz type Saljut stations carrying Soyuz panels besides the rear (only) docking port:
- 22,660 replies
-
- 7
-
-
- totm march 2020
- mod
-
(and 2 more)
Tagged with:
-
Sure, the cylindrical section of 290mm diameter is up to twice as long on Spectr, Priroda, Zarya and Nauka as on the TKS/VA or Kvant-2 and Kristall. The FGB is adapted from the original DOS Modules. The 2900mm diameter section of 3510mm length was taken, as well as the 1200mm long taper to 4100mm, but the 4100mm diameter section was shortened and the bottom of the fuel tank from protons third stage was used to form the aft section (where the RD-0213 sits is now the docking port). This way the thrust load of the small diameter was nicely transferred to the best fitting diameter of the proton (as well as the reusability for the 4100mm adapters to mount the payload to the proton), and some headroom to install the second cockpit in the tks was found. Its the usual russian way - why develop something completely new, if existing parts can be adapted. Just like the whole service compartment of a sojuz was used in the first saljut instead of the rear docking section, then the new rear docking ring but still sojuz solar arrays etc etc. You can see the development of the FGB (and the DOS) from the days of TKS/VA (just as decribed above) with the short 2900mm dia. section and (on the DOS "saljut3" - an actual Almaz - no frontal docking compartment but the remains of the interface that should hold the VA of the Almaz itself). Saljut 1 (never to carry an VA) had the docking compartment attached to the front of the 2900mm dia. section, and also Kristall and kvant-2 used such a three-diameter setup to increase the usable space. This very small diameter section was then ditched and the 2900mm section was extended instead, and later extended again with the small docking "globe" on front of Zarya. You can also clearly see that the later TKS can carry two sets of the 4*2 arrangements of cylindrical tanks plus radiators - one on the "original" and one on the "elongated" hull of the 2900mm section. Some images: A "short" FGB: and a "long" one:
- 22,660 replies
-
- 3
-
-
- totm march 2020
- mod
-
(and 2 more)
Tagged with:
-
Kwant had a standard short FGB taken from TKS/VA without a VA but a nosecone-fairing instead of the VA as protons jettisonable fairing used in TKS/VA launches only reached up to the interface between FGB and VA, with the VA having no additional fairing. The MIR modules as well as Polyus, Zarya and the still yet to be launched Nauka are based on the the longer FGB (consisting of the "sealed instrument compartment" пго-1 & пго-2 (the double cone of all FGBs) and the added пго-3 plus (not for Polyus) the docking adapter that where never to be fitted with an VA. So yeah - TKS and MIR FGBs should not be the same.
- 22,660 replies
-
- 1
-
-
- totm march 2020
- mod
-
(and 2 more)
Tagged with:
-
Depends on how you scale weight. If based on a 0.64 spatial axis shrink, weight should go down .64^3 times as does the volume, not just by linear scale.That's how I scale fuel (plus density of stock fuel/ox and the different ratios of it). Comes close to stock units of the same size.
- 22,660 replies
-
- totm march 2020
- mod
-
(and 2 more)
Tagged with:
-
The 37KE Module without tks-5 should be around 11 metric tons compared to the more or less 19 tons of the tks based modules (kvant-2, kristall, spektr), so about 57-58% of those.
- 22,660 replies
-
- 2
-
-
- totm march 2020
- mod
-
(and 2 more)
Tagged with:
-
does the transform smokePoint exist on the model?
-
One emissive animation.
InsaneDruid replied to Alcentar's topic in KSP1 Modelling and Texturing Discussion
No, cutting the animation component (like you would delete the mesh renderer component on a collider part) from (one of) the nozzles and putting it to the parent of the nozzles and referencing it there in the cfg. -
One emissive animation.
InsaneDruid replied to Alcentar's topic in KSP1 Modelling and Texturing Discussion
If i can remember it correctly then the animation component must sit on the parent part that has the nozzles as children? -
Collider Mesh Appears In-Game
InsaneDruid replied to 2001kraft's topic in KSP1 Modelling and Texturing Discussion
Some questions: first: why so many individual colliders? This could be done with one, half-spheric icosphere mesh as the collider, coulnt it? You cant walk into it anyway, or can you? Is the "empty" underside (from the physics engine point of view) really neccessary? Then, what is group_0 and instance_0? From the image of the unity Assets explorer it looks like they have mesh data, too? Or not? I would look for the problem in this area. First, I would delete the colliders and export it without them, check ingame. I bet the problem still occurs. Then delete the group_0, check, delete instance_0 and check ingame again. This way you can really identify the problematic mesh. You could export this dome as a unity package then we all could have a look. -
I tried to implement the idea of just importing blender models directly into unity. The reasons why I did not stick with it are: Version control. I like to save early, save often keeping older versions of the blend files. I tend to work with big blend files that contain all the parts of a project. The whole Proton with every part is just one file. I tried importing it in unity -> took ages. Reasoning for this is that it allows me to model a project as a whole, then splitting it up and exporting the single models out of it. Especially during the initial development I carry a lot of helper structures, shrinkwrap targets, baking sources and a metric ton of image empties with me. Combined with the first point -> current folder size of my blend files for the TKS is 5GB that i would carry around in unity. Another level of backup due to the presence of the fbx files on another drive.
-
Texturing bump help, any clues?
InsaneDruid replied to steedcrugeon's topic in KSP1 Modelling and Texturing Discussion
correct unity+parttools version? -
Thanks to @StoryMusgrave, it should be fixed now. Fix is available @GitHub and in the next Update.
-
X Axis orient in unity
InsaneDruid replied to /not/pol/'s topic in KSP1 Modelling and Texturing Discussion
-
Fixed on GitHub
-
Ahh, thanks! I'll try to recreate. EDIT: A fix will available today on GitHub and for CKAN/SpaceDock in the next release. For now, go to Settings->Difficulty Settings->Advanced and disable "All Part upgrades applied in sandbox"
-
That images (?) aren't working. I verified the mod with a new fresh test-install with realplume. Engines are working, all saved crafts (Proton Light, Medium and M are working. What mods do you have installed besides the Proton and Realplume? Can you link a screenshot of your gamedata?
-
You don't have to use armature bones. Or transformation constraints. Your setup seems fine from the screenshot. I think you have animated each of the panels individually, as the multiple nla stripes suggest. This is totally fine. The setup described in my previous post just has the single advantage that just one object is animated with keyframes, so that tweaking and changing the animation may be a bit easier (especially when many panels are connected). But animating each individual panel and using a parent-child relation is totally fine, too.
-
I do the same, but keeping all the layers as layer groups (diffuse, specular map and heightmap) and or smart objects - so that I just need to adjust some blending options or smart filters to turn a diffuse into a height/spec element) in a single .psd. The heightmap gets than exported into shadermap 2 to be turned (and tuned) into a normal map. Though the 30 mins estimate stated above is rather low in my opinion. The first run will probably be slower until you get a feel for the height and specularity - ie how deep/high for example a groove shall be to not alias, not be overdone and look ok etc.