Bonus Eventus

Members
  • Content count

    402
  • Joined

  • Last visited

Community Reputation

643 Excellent

3 Followers

About Bonus Eventus

  • Rank
    Purgamentum init Operante
  1. Reworked the avionics panel for DA-42, this will make RPM easier
  2. Just in case you were wondering how high my altitude is... Let the UI nightmare begin
  3. This is a cool 360 video of one of the modules on the ISS
  4. Thank you @sarbian, haha, that line adding the component to itself as parent shouldn't have been in there to begin with, it was old code.That JPLRepo post helped a lot. I was confused though about whether I needed to duplicate both the near and far camera or could use one camera at a higher depth. I've since revised the code. This is where I got last night. using System; using UnityEngine; using System.Collections; using System.Collections.Generic; namespace Utilis { public class UtilisDisplay : InternalModule { [KSPField] public string cameraName = "utilisCamera"; [KSPField] public int width = 512; [KSPField] public int height = 256; public Camera camera; public RenderTexture renderTexture; private Material material; public override void OnAwake() { if(!HighLogic.LoadedSceneIsFlight) return; renderTexture = new RenderTexture(height,width,24,RenderTextureFormat.RGB565); renderTexture.anisoLevel = 0; renderTexture.antiAliasing = 4; renderTexture.filterMode = FilterMode.Trilinear; renderTexture.isPowerOfTwo = true; renderTexture.Create(); while (!renderTexture.IsCreated()) ; material = gameObject.GetChild("model").GetComponent<Renderer>().material; camera = internalModel.FindModelTransform(cameraName).gameObject.AddComponent<Camera>(); camera.fieldOfView = 100; camera.cullingMask = (1 << 0) | (1 << 1) | (1 << 4) | (1 << 9) | (1 << 10) | (1 << 15) | (1 << 18) | (1 << 20) | (1 << 23); camera.nearClipPlane = 0.001f; camera.farClipPlane = 1000000000f; camera.targetTexture = renderTexture; Camera[] fCameras = FlightCamera.fetch.cameras; foreach(Camera c in fCameras) { if(c.name == "Camera00") { camera.depth = c.depth + 1; } } camera.enabled = false; camera.Render(); material.mainTexture = renderTexture; } } } The problem of the main camera flipping out was caused by a null reference I missed in the log. I didn't understand that dTransform was not where the renderer was located, because when I compiled the .mu file I added the part tools component directly. dTransform has no renderer or mesh, what I needed was the "model" transform. As of this moment the problem I'm still having is that the render texture appears completely black. At first I thought it was a depth problem. I thought maybe one of the gui cameras at the lowest layer renders a black screen. But that turned out to be wrong, because I switched the depth order and nothing changed. I was thinking I would add the second camera after I confirmed I can render texture was working. BTW, I too am confused about RenderTexture.create( ), the docs are a bit ambiguous: "RenderTexture constructor does not actually create the hardware texture; by default the texture is created the first time it is set active. Calling Create lets you create it up front. Create does nothing if the texture is already created."
  5. Yeah, we'll see, I'm trying design windows in such a way that players will get the best, most desired view possible. So, about RPM... I tried some different settings and read up a bit about KSP performance issues in general. What I found out was, that (unlike what I had thought) KSP is mostly reliant on CPU cycles and not the GPU. I had thought the lag I was experiencing was do to a billion draw calls to render all of the screens. However, I was wrong. I switched some KSP settings around, reduced my screen resolution, closed some background apps, etc. The performance was greatly increased without the cost of a large difference in appearance or gameplay. With that RPM was very playable, and I almost landed on the mun in one go without leaving IVA, almost, didn't quite know where some things were in the ALCOR capsule. I made a sprite sheet for an open source font I plan to use to make RPM pages with a font called Roboto. It's a monospaced font (each letter occupies an equal space) which has a nice modern aesthetic. There's also a condensed version which I think could work well as a display font. I was looking around for UI inspiration and remembered I liked the look of the avionics in the film The Martian. I think the above is very do-able. I'll need to do some more experiments to know for sure though.
  6. I did a simple test with an internal module I've been tinkering with, and caused all kinds of mayhem. The module is simple. It finds a prop transform for a screen model and an empty gameObject, then adds a camera component to the empty gameObject and adds a renderTexture to the screen model. The camera then has its targetTexture assigned to the renderTexture. That's it. The game loads fine but when I load the IVA on the pad the main cam is rotated 90 degrees on the x axis or sometimes is flung into deep space before the game crashes. I'm guessing it has something to do with layers and tags. I'm sure there's some camera voodoo I'm unaware of. @linuxgurugamer would probably know what the best practices are. public class UtilisDisplay : InternalModule { [KSPField] public string dTransform = "dTransform"; [KSPField] public string cameraName = "utilisCamera"; [KSPField] public int dPixelWidth = 512; [KSPField] public int dPixelHeight = 256; private Camera cameraFeed; private Transform cTransform; private RenderTexture displayTexture; private Material displayMaterial; public override void OnAwake() { if(HighLogic.LoadedSceneIsFlight) { UtilisTools.Log(this, "Start!"); displayTexture = new RenderTexture(dPixelWidth, dPixelHeight, 24, RenderTextureFormat.ARGB32); displayMaterial = internalProp.FindModelTransform(dTransform).GetComponent<Renderer>().material; cTransform = internalProp.internalModel.FindModelTransform(cameraName); cTransform.gameObject.AddComponent<Camera>(); UtilisTools.Log(this, "Camera created"); cameraFeed = cTransform.gameObject.GetComponent<Camera>(); cameraFeed.fieldOfView = 110; cameraFeed.transform.parent = cTransform; cameraFeed.transform.localPosition = Vector3.zero; cameraFeed.transform.localEulerAngles = Vector3.zero; displayMaterial.mainTexture = displayTexture; } } } The log is spamming "Look rotation viewing vector is zero"
  7. Reworked the low poly habitat hull after my cloth experiments. I felt it needed some more geometry (roundness) to convey the softer quality of the fabric material. Had the idea to add cupola module style windows to the hab airlocks. I also started the rigging process, finding a novel way to procedurally animate the 12 pistons and 3 telescopic arms based on distance to a target locator, so now they all sync when the hull extends. Taking a break from centrifuge design, I returned to the DA-42 capsule and fixed some weird bugs with the IVA, did a couple of touch ups to the exterior texture, and began working on the IVA control panel. I originally wanted to use RPM for the controls, but after doing several tests I'm pessimistic about about how much lag I experienced as well as several crashes. Also, I almost think RPM is too expansive for what I had envisioned—more of a modern day SpaceX style touch display with a few analog controls. Writing an internal module which can manipulate an external part isn't that difficult, I've already done so many times on the road to completing ModuleCentrifuge, however mapping button clicks to action groups,or throttle controls, or what have you might be tougher than it looks. I spent most of today coding a simple internal module that would map a camera feed to a screen, but it looks like there's a lot of things squad does with cameras that I'm not aware of. Just by instantiating a single camera component at runtime I caused the game to go into an infinite loop after the kraken took over my main cam hurling my pov into deep space, lol. Maybe RPM is the way to go after all...
  8. I had an epiphany today regarding soft body simulation. I tried draping pieces of cloth in small sections across the hull, and the detail level skyrocketed. That's a good thing, because now the mesh has the correct scale of deformation. This ought to make a decent normal map considering how close it is to the original low poly model. Only question is will this still look good with stock models. I think if the textures are simple it might work. If not I could try this again with a slightly more cartoonish scale. Regardless, I know I'm going to put cloth to good use in the IVAs
  9. Experimented some more with the hull of the hab wheel. This version is pretty high resolution, coming in at 5,000,000 polygons. Some things are working, some things aren't. The cloth look is sort of there, but it looks more like thick rubber. Throws the scale off. I mocked this up using soft body simulation, which I'm still a n00b at. I learned a lot and I have some ideas I want to try tomorrow. I'll post back with more soon. How long have ago did I start designing this? 6 months? Gah...I've got to stop doing look dev
  10. Worked on the normal map for the inflatable hull last night. Normal map from a distance. Close up of normal map. High resolution sculpt used to make the normal map. I feel like I might have to tone it down a bit, might be a tad too realistic.
  11. seems like a compiler issue. Check your file paths in your programing environment (visual studio or whatever you're using)
  12. Yeah, however, one could imagine a scenario where external cameras malfunctioned causing zero visibility. I imagine you would want to have a line of sight of the rest of the ship. If nausea is a problem, you could always pull a shade down, like when on an airplane.
  13. The short answer is I don't know. I've been working on a dock able version of the centrifuge module, however it's problematic for several reasons. If all else fails I'll make a smaller centrifuge as well.
  14. This is a WIP of the 30M diameter centrifuge. The couplers that attach the telescopic arms of the hub to the inflatable hull need to be refined some more. Haven't figured out where the windows will go either. The inflatable hull is telescopic as well, taking inspiration from Bigelow Aerospace's BEAM. The gas struts (blue) help extend and retract the hull. Inside the hull, telescopic rails help keep the sections curved as they extend from a contracted state. The hull walls are 274.33mm thick. The diameter of the hull profile is 1.875m at the widest (measuring from the outside) tapering to 1.7m at its narrowest. The stack attachment hinges are 2.5m in diameter.