InsaneDruid

In Unity. Or already in your 3d modelling app.

Then your setup should look like this: gimbalTransform | --->nozzle_mesh --->thrustTransform or even: gimbalTransform | --->nozzle_mesh --->thrustTransform --->smokefxTransform with the exhaust fx coming out of the thrustTransform and the smoke trail from the smokefxTransform. Key here is to have a separate gimbal transform (that even COULD be your mesh) to which the thrustTransform (and smokefxTransform) are parented to. So they move with the gimbal, but can be placed along the thrust axis of the engine). OR: gimbalTransform | --->nozzle_mesh --->thrustTransform smokefxTransform with the smoke not reacting to the gimbal (and positioned rather below the nozzle) which might look more natural with the smoke beginning later and only beeing incluenced by the flight path of the vehicle.

Just to exclude the possibility (so sorry if this ready like "have you plugged your computer to the mains?" ) : have you fueled the rocket on the pad (or in the VAB)? The craft files have empty tanks on the launch vehicle, just the breeze is already tanked - like in reality. Use the generator in the launchpad to fuel it on the pad (like in reality) or set the fuel levels in the VAB. If this wasn't the problem, please shortly describe the circumstances. Stock KSP, KSP + Realfuels or Realism overhaul?

The cheat sheet is just wrong. Unity uses a left-handed coordinate system. Blender uses a right-handed one.

Beautiful modelling and texturing. Love that IVA! Love the AO bake! Really nice mod!

This here is the Modelling and Texturing Discussion subforum. I can't see the question and/or answer to something related. So it's clearly posted in the wrong forum. But now as we are here: just a tip for further modelling: never use pure white (or black) in a texture. Instead, use something like 80 or 90% black or white. So that the surface can catch shadows and highlights better. Believe me, it will look so much better.

Easy way: just model everything in blender with z up and y back (the normal mode in blender). Then export to fbx with the following As you can see. the exporter already addresses the problem with the Forward: -z forward and UP: Y Up setting (this is even selected by default). This way your model will be imported fine with the correct orientation in unity. Only thing where you need to think is when setting up empty transforms in blender and want to align thrust axis, and smoke/exhaust fx axis. One tip: make an empty transform and set all your meshes and empty transforms (for said exhaust fx, nodes, etc) as children of this empty. This way the said empty will define the origin of your model, so you don't even need to centre it around the actual origin in blender and unity but can freely position it in your scene. For example: All the objects that form the capsule with all its antennas etc are children of the empty named "va_capsule_origin". EDIT: and yes, if you want your model rotated in the vab, rotate it in blender or unity (i usually try to set up as much as possible in blender).

Here is my workflow. Works fine for me, even for armature+bones based anims. Blender: Export to FBX. Under Version, select "FBX 7.4 binary". Under "Main" enable "Selected Objects" and "!EXPERIMENTAL! Apply Transform". Under "Animation" enable "Baked Animation" and disable the Rest. Unity: Select the Model. Under "Rig" select Animation Type "Legacy" and "Store in Root (New)". Under "Animations" rename the default clip to something useful and if you need to (on models that have more than one animation you usually store these in one big timeline in blender and separate them by the start/end frames in unity) add more clips and apply the start and end frames of these accordingly.

There are multiple ways to achieve this: 1) Use a surface attachment node which is not located in the center of the ring, but shifted outwards to sit on the surface of the mesh it is supposed to be attached to. You have to use the old, "classic" way of defining such node in the config: node_ring = x-position, y-position, z-position, angle x, angle y, angle z, size attachRules = stack, srfAttach, allowStack, allowSrfAttach, allowCollision Say your ring is 1 unit in diameter, so it would look like this: node_ringp = 1, 0, 0, -90, 0, 0, 1. attachRules = 0, 1, 1, 0, 1 Could be +90 though,I cant remember which way it turns. PRO: can be used on any model with the correct diameter CON: might need some tries to get the parameters right. node coordinates have to be adjusted each time the model is scaled Also, the part would be not be attached cantered so it could introduce some wobbling/instability. 2) you can use nodes defined via a node{} entry in the config that uses an empty gameobject to place the node and its direction. If you do this, place a empty on the surface of the inner vessel, and let its positive z-axis point outwards. Also, place another empty on the ring in the same location as the first one, but pointing its z-direction inwards. Config on the Core Model NODE { name = top transform = node_CoreTop size = 3 method = FIXED_JOINT } NODE { name = side transform = node_CoreSide size = 1 method = FIXED_JOINT } NODE { name = bottom transform = node_CoreBottom size = 1 method = FIXED_JOINT } Config on the Ring Model NODE { name = side transform = node_RingSide size = 1 method = FIXED_JOINT } PRO: using the node{} method provides very precise nodes that are easy to setup (position and direction can be seen in 3d editor and unity node stays in place regardless of model scale, as it scales with the model ring can be attached higher or lower by just moving the node_CoreSide up or down (or having multiple of then in different heights) CON: might need some tries to get the parameters right. Also, the part would be not be attached cantered so it could introduce some wobbling/instability. And it needs the node{} setup on the core model. 3) you can use nodes defined via a node{} entry in the config that uses an empty gameobject to place the node and its direction. Like above, but with centered nodes. If you do this, place a empty on the center of the inner vessel, and let its positive z-axis point up or downwards (like a top or bottom node). Also, place another empty on the ring in the same location as the first one, but pointing its z-direction in the opposite direction (down or up). Config on the Core Model NODE { name = top transform = node_CoreTop size = 3 method = FIXED_JOINT } NODE { name = center transform = node_CoreCenter size = 1 method = FIXED_JOINT } NODE { name = bottom transform = node_CoreBottom size = 1 method = FIXED_JOINT } Config on the Ring Model NODE { name = side transform = node_RingCenter size = 1 method = FIXED_JOINT } PRO: using the node{} method provides very precise nodes that are easy to setup (position and direction can be seen in 3d editor and unity node stays in place regardless of model scale, as it scales with the model ring can be attached higher or lower by just moving the node_CoreCenter up or down (or having multiple of then in different heights) ring is attached perfectly centred CON: needs the node{} setup on the core model, like above. I use the method 3 on several models (for example the ring droptank of the breeze) and it works perfectly. There is no need for separating the inner model.

AH ok so I got the documentation right. Could it work the other way around - making a persistent variable (that controls the animation) be non-persistent? Before I added the RasterPropMonitorComputer module module to fix the problems mentioned by me on github (and thus realized it was the RasterPropMonitorComputer that made a persistent var persistent) it was OK, as the animation resetted to the same state as the zoom. Is this somehow possible? What would work though is making several meshes that function as projecting surfaces for different RPM monitors -> each with a different camera config. These meshes then could flip 90° into a surrounding non-transparent mesh, depending on the same persistent variable as the switch rotation. IE on switch pos 0 plane a is visible, on switch pos 1 plane a gets rotated out of view and plane b is visible etc. But having at least 3 cams render to a surface that then is not really used seems wasteful.

Sorry to bother you again. I am stuck finding a way to switch pages or adjust the zoom of a camera depending of the state of a perPodPersistent variable. Currently, my setup is this: the camera is bound to a page and uses globalbuttons to zoom in and out MODULE { name = RasterPropMonitor .... yadda yadda screen transform etc... globalButtons = collider_wide,collider_zoom ... PAGE { name = tks_va_vzor_zoom_page cameraTransform = va_capsule_nodeVzor cameraAspect = 1.0 zoomFov = 25,65,3 zoomButtons = 0,1 } } the same colliders "collider_wide","collider_zoom" are used in a JSINumericInput to affect a perPodPersistent variable that is then used in a JSIVariableAnimator to drive the rotation of a rotating selector knob. The problem is: the state of the JSIVariableAnimator is saved in the persistent variable, but the state of the camera zoom is reset every time when the user is switching to the vessel. Is there a way to control the zoom lever of a camera, or - if this is not possible - switch to different pages (that are configured with different zoom levels of a camera) by the state of a variable that is pod-persistant? Again, sorry if this is already answered. Unfortunately, my first ever ksp prop is also a quite complicated RPM-driven one.

Ah, ok then. IT sounded like you where getting something like hundreds of objects or so. They way you work is perfectly fine. Technically, you CAN set up a animation that only affects parts of a single, object (via armatures and bones and vertex groups) but that is using a bit of CPU ressources and is not practical for animations like you describe. You would do this for the variable exhaust openigns on jet engines etc, or kerbals etc. So your workflow is perfectly fine. To align the uv maps of multiple parts onto a single texture i use https://blenderartists.org/forum/showthread.php?339369-MultiEdit-version-5-Multiple-Objects-Editing This addon (there are some that work similar) automatically merges the selected meshes, allowing for a "combined" UV editing of all the objects, and re-splits them automatically. Works quite nice. Soemtime though, i just merge and re-split meshes after uv editing manually.

Why and when do you have multiple objects? What are you trying to animate? Usually just animating an object doesn't make it more than the original object. What software? Describe your workflow a bit. What do you mean with "log scale and rot"?

Is there a guideline on which is faster: using one JSIVariableAnimator with many VARIABLESETs or using multiple JSIVariableAnimator with lessVARIABLESETs? Using more could allow for some of them being refreshed less frequently, thats for sure, but if all are polled every frame, which is faster?

What was it?

Try cutting the animation data from LBSI_LC_03_Launchclamp_v002 and paste into ClampRoot. Its like any other component (like a render component or a physics component) that you can cut and "paste as new".

trf_animationRoot_name = ClampRoot and the first screen shot in your post don't seem to match, as the animation seems to be bound/stored in to LBSI_LC_03_Launchclamp_v002, not ClampRoot. Either cut the animation data from LBSI_LC_03_Launchclamp_v002 and paste into ClampRoot, or change trf_animationRoot_name = LBSI_LC_03_Launchclamp_v002. trf_animationRoot_name = is the empty game object that holds the animation and the animated parts. In your case it currently only holds the animated parts, not the animation. Besides this: try reducing the amount of different mesh objects in your model. There are quite a few of them, like all those single "bolts" meshes. They all eat up draw calls. Also: less colliders would work, too. No need to have one in the clamp

You can get an better result with some custom normals on these trees. Currently, the different "cardboard pieces" all get lit like a pile of cardboard. If you surround the treetop with a sphere or a stretched sphere on the more prolonged trees, and project the normals of these spheres onto the tree model, you get a much more uniform and natural lighting (lighter on top, darker towards the underside of the treetop etc. Some images: first, two of the trees as they are: you can see that one part is brighter than the other, creating an artificial and vertically split look with a very bright stem even directly under the treetop in the shadow. now, with custom normals: more voluminal looking, with brightness gradient from top to bottom. and the quick n dirty setup I used: (you can see the modifier settings on the other screens) You can read more about it here: http://blendernpr.org/lets-talk-about-normals/

The problem is quite common when two alpha blended surfaces are overlapping. You can try to use a shader that uses additive lighting (like ksp/particles/additive) or otherwise tries to circumvent the problem (is about draw order using zbuffer - have to confess i never dug into the depths of this) by using deferred rendering. KSP/Particles/alpha blended maybe? Actually: just try everything available.

PS: oops: didnt read that hidden content. So if its a <whatever a KK is> problem, this might not help: So you want to build a launch platform without a tower and moving arms etc, but just a platform to attach under your rocket? So, you launch transform is the place "where the rocket is attached to", this is what I called "launchpad_nodetop" on my proton launchpad. (I disabled the actual concrete mesh surrounding this pad in these images so you can see better) Then, you need another such gameobject/empty/transform pointing the other directing. I called mine "launchpad_ground_empty". Then its just a matter of a quick config. Add the node like any other node, and the ground empty inside the module LaunchClamp // --- node definitions --- NODE { name = top transform = launchpad_nodetop size = 3 method = FIXED_JOINT } // --- module parameters --- MODULE { name = LaunchClamp trf_anchor_name = launchpad_ground_empty trf_animationRoot_name = launchpad anim_decouple_name = close } As an alternative, you probably could make it just as any other "dumb" object without the module LauchClamp if you just add the upper node to attach the rocket and put an module Decoupler to this node, so your launchpad would be just a heavy object left behind.

Of course not cryo-chilled and not into temp ranges that would lead to thickening and thus clogging of the fuel lines (breeze tanks are insulated against this). ^^

To my knowledge: Proton-M over K: Changed flight control system (located in the upper compartment of s3), the new one was more capable and smaller so the small bulges around the perimeter of that upper compartment went away. The RD-253 was upgraded to the RD-276 specs and finally the Breeze-M was introduced as a new upper stage (though the M can fly with "ye olde" Block-DM). So visually: the new upper stage, if used and the absence of the small bulges. So, the changes are more spec wise and internally than externally visible thigns. Then, a Proton-M isn't a Proton-M, too (it had several phases of upgrades already). First phase upgrade: The helium tanks on the Breeze-M are different, they removed one (so actually the current Breeze droptank represents an older one), the amount of fuel is a bit different in the Breeze (less) and Proton (more, thanks to cooled propellants), software changes on the Breeze, different main engine in the Breeze. So visually: just the one less helium tank. Second phase upgrade: Upgraded engines on the first and second stage, thinner tank walls, use of composite structures on the s2 (the skin now actually has the visually more interesting riveted aluminium bump-map), and also the use of unpainted versions of the Proton-M to maximize payload capacity. Breeze has less pressure tanks (2 instead of 6 actually represented in the current model) in her upper inner compartment, moved avionics compartment to rebalance her. The 11d458 are spec improved. So visually: the bump-map on the aft compartment of the s2, the amount of pressure tanks on the Breeze, and maybe an unpainted version. Third phase upgrade: Didn't change the design to my knowledge. The most recent phase IV incorporated material changes and telemetry system upgrades, so not much visual change. Summa summarum: the bulges, the amount of pressure tanks in the breeze, a material change only visible in the bump-map, and the upper stage.

The can be exported in on file (if .obj, fbx, even .blend.) but they have to be separate meshes in those files.

Got it to work. Aligned the Axis according to your prop, and then it was just a rotation of 180 around x and z (blender axis) of the mesh data, like you said. Thanks! PS: also like the use of particles/additive shader to avoid the sorting issues that coplaner alpha blended materials have while maintaining the smother edges! Nice!

@nli2work maybe you can help me with making a navball prop. I started by importing the stock iva navball via the mu importer into blender, so i can focus of getting the axis right. But for the love of god i cannot get it right ingame. I only just managed to get a navball that, is some sort of "inverted". Top is bottom, prograde is retrograde, normal is antinormal etc. See the screeny. Stock one on the left, my re-exportet one on the right, just without the base rendered to allow a better view on the actual navball for now. So if you or anyone could show a screenshot of a working navball prop from unity with the axis highlighted? Also, can somebody tell me what the lines iconUp = 0, 1, 0 anchorName = Anchor do? As of now, this prop drove me insane..