• Content Count

  • Joined

  • Last visited

Community Reputation

224 Excellent

About soulsource

  • Rank
    Sr. Spacecraft Engineer

Profile Information

  • Location Innsbruck/Austria
  • Interests Physics (I've got a PhD on that...), science in general, computers, programming, gaming (I'm currently working as a game developer), other nerdy things.

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. soulsource

    Rating difficulty of KSP celestial bodies

    In my opinion Eeloo is easier to return from than Moho, at least without TACLS. I agree with magnemoe that Tylo is the hardest body to land/return from. Actually I think we need two lists, as there's usually quite a difference in difficulty between getting to a celestial, and returning from there. Just look at Eve. It's quite easy to get and land there, but returning is quite a challenge.
  2. I'm rather certain such clauses in an EULA aren't legal and therefore void in many countries. Edit: "The EU requires Member States’ courts to presume that the arbitration agreement in consumer contracts is an unfair term, if it was not individually negotiated by the parties after the dispute arose" -
  3. soulsource

    What was the barn?

    The barn was a concept for the lowest level of the KSC buildings. Some people still want to have it.
  4. soulsource

    Low fps Astronomers visual pack

    Are you on Linux? Unity didn't properly convert Scatterer 0.336's shaders to GLSL, and caused them to unnecessarily read/write to GPU memory quite often (see the discussion in the scatterer thread). The workaround for that Unity issue has been merged already on Github, but didn't end up in any released version of Scatterer yet. Edit: As a temporary workaround you can try using the Shaders file from Scatterer 0.331, but that is only a partial fix, as the Scatterer 0.331 shaders suffer from the same Unity issue, however the broken code is not running as often.
  5. I agree. For instance, FAR on default settings, has significantly lower drag than stock.
  6. soulsource

    [1.5.*] AFBW Revived (Joystick & controller mod)

    Did you get the required dependencies (as listed in the first post, right at the beginning)? For me the (Linux version of) the mod is working perfectly fine.
  7. soulsource

    Why is the engine plate a decoupler?

    Wait, what? You don't need an extra decoupler if using an engine plate? Why didn't anyone tell me?!?
  8. soulsource

    Slow orbit with mun

    It's not possible to be pulled into Mun's orbit in Stock. Unless you decelerate you will always get a flyby.
  9. soulsource

    The Landing Legs & Gears Is Killing Me!

    Hmmm, in 1.5 it seems that there's some crazy "lock orientation once movement gets small enough" code in place. I just had a lander on Minmus, that had SAS turned off, and trim at zero, and still it ended up tilted (with 2 out of 4 legs above the ground). Small torques (reaction wheels) could only make it oscillate around that orientation. Once a stronger torque (RCS) was applied, it shifted, but just to find a new "equilibrium" orientation, that wasn't realistic either... Either that, or the collider of the Poodle is now a meter longer than the visual model...
  10. Okay, so I'm going to test if the issue persists with the latest Unity version, and if yes, file a bug report. Edit: I can confirm that the same issue persists with the latest Unity build for Linux (2018.2.something). Bug report is in the process of being filed. Edit 2: Bug report has been sent using Unity's Bug Reporting tool, including a minimal project with a really minimal shader for easy reproduction. Let's see if there's an answer. Edit 3: No news from Unity yet. I should have filed the bug report at work, where we have Pro licenses, instead of home using a free license..
  11. As a small sidenote: I could not stop playing with this Linux issue, and it seems that the HLSL->GLSL converter of Unity is to blame. Maybe we should file a bug report there... I've looked at the generated GLSL code using Mesa's shader replacement feature, and the generated code is everything but compiler friendly. Here's an example (one of the shaders that uses dither): Unity converts the local compile time constant array into an uninitialized global array, that then is copy-initialized in the shader's main function . Obviously the llvm AMD shader compiler is seeing this write access happening, and decides to make it a real, in-memory array instead of compiling it in as constants. I've made some trivial edits to the generated GLSL code, and that also brought performance up to speed (tested with Mesa's shader replacement feature again - I don't know how to make Unity do the same thing ): The only difference being that the array is const again, and initialized right at declaration instead of copying the single values into it in the main function... So at least we now know what was going on...
  12. So, sorry for the confusion. The pull request is open again, and should now work on shader model 3 as well.
  13. What I've found up to now is that the Bayer pattern array seems to be placed in private memory, instead of being hardcoded or stored in registers... I think the following snippet compares the same shader, once with the Bayer pattern as an array (old file), and once with it computed with the formula from Wikipedia (new file): (think, because I have no experience when it comes to reading assembly). Here's a pull request for your consideration: Edit 3: Please disregard, it's not building for Windows... As said, this change improves performance on Linux with AMD hardware a lot, but as it does more computations (instead of using precomputed values), it might decrease performance on other platforms and should therefore be tested before merging (I would actually even consider conditional compilation, in the worst case)... Edit: The merge request requires shader model 4. I don't know if scatterer supports d3d9, but if it does, please tell me, then I'll rewrite it so it does not use any bitwise operators. Edit 2: I just saw that when building for Windows shaders for SM 3 are being built. I'll fix that. Edit 4: See post below.
  14. I might get crazy: By just removing the dither function completely (meaning: just making it return the input value) performance drastically increased on Linux. Like, from 35 to 45 fps on my machine... Edit: It has something to do with the size of the bayerPattern. Edit 2: That gives me an idea. The matrix can be replaced with a formula ( I'll try that tomorrow, and if it indeed improves performance, there will soon be a pull request.
  15. Hmmm, it seems performance on Linux went down the drain with The culprit seems to be the added dithering in atmospherePostProcessing32bitViewSpaceDepth.shader. By undoing --- a/scatterer/Shaders/scattererShaders/Assets/shaders/atmospherePostProcessing32bitViewSpaceDepth.shader +++ b/scatterer/Shaders/scattererShaders/Assets/shaders/atmospherePostProcessing32bitViewSpaceDepth.shader @@ -306,7 +306,7 @@ Pass { // inscatter*=eclipseShadow; //#endif - return float4(hdr(inscatter)*_global_alpha*returnPixel, 1); + return float4(dither(hdr(inscatter)*_global_alpha, screenPos)*returnPixel, 1); I got performance back up to acceptable levels, also with shaders from 0.0336. I'll investigate this further, because the dither function itself looks reasonably benign, so there has to be something crazy going on in either Unity's HLSL->GLSL converter, or in the AMD shader compiler... (I originally thought that we get register spilling, but meanwhile I'm rather certain that we can rule that out...)