Jump to content

rbray89

Members
 View Profile  See their activity

  • Posts

    2,719

  • Joined

  • Last visited

 Content Type 

Everything posted by rbray89

  1. rbray89
    That fixes the clouds disappearing. I don't think it fixes the camera issue.
  2. rbray89
    Yeah... Pretty sure you can work around it by deleting the PartFX.dll, but I haven't tried it.
  3. rbray89
    When you run SetRenderTarget You can specify a mipmap level. I think there must be a unity bug that doesn't take into consideration the way you are building the texture. I'd expect if you were using Blit or a camera it would just work though.
  4. rbray89
    I assume both useMipMap and generateMips are set to true? A decent work-around would be to generate the mips manually...
  5. rbray89
    as per http://docs.unity3d.com/ScriptReference/RenderTexture-useMipMap.html what is the resolution of the texture?
  6. rbray89
    The problem there is that you'd also need another camera. The idea of using a plane infront of the primary camera, is that you have the depth buffer already.
  7. rbray89
    Hmmm.... it may have been that the dv/du values weren't being calculated properly? You could always test by selecting a specific mip map level to see if they are being generated properly, or it is just the selection.
  8. rbray89
    Out of sheer curiosity, what was the issue?
  9. rbray89
    Items in vab have to be blurry... that is how this mod works. It shrinks the textures until they are needed I'll have to look into the parachutes though. Is that a mod using them? Do you have any mods that use/add parachutes?
  10. rbray89
    Gotcha... Though, with any geometry based approach you'd have the issue with off-screen rendering... You'd have to alter the rendersphere to make sure it was rendered anyways. I look forward to see what can be done with shadow mapping
  11. rbray89
    It shouldn't... What models is this happening to? Do you have logs?
  12. rbray89
    I think I may have a solution... It would use something similar to what you do with the ocean. A mesh applied on screen, moved to the locations on the depth buffer, and the depth buffer normals extrude the secondary mesh. Downside is that you'd need both a depth buffer and normals buffer. EDIT: The issue stems obviously from not all vertices being connected to each-other. In regular objects this of-course is to maintain proper normals rather than sharing them and making them inaccurate at hard edges (your cube example). In the case of terrain however, the surface is made up of disjointed quad objects, meaning the vertexes could never be connected. I think the secondary screen mesh should work though. You'd probably have to filter out the cases where the vertex doesn't hit anything, but you already do a good job in the ocean anyways.
  13. rbray89
    Cool! I was wondering how you were doing that. I assume you extrude vertices that maintain normal perpendicular to the ray?
  14. rbray89
    I can't replicate the alcor issues. All the textures show up in perfect detail. Make sure your texture settings in KSP are set to max, and try deleting the cache folders in C:\Users\rbray\Documents\ksp\ksp-x86-1-0-5\GameData\DynamicTextureLoader\Plugins if you were running an older version at some point. The slight artifact is a result of re-loading the textures and saving as PNG. It results in "double" compression. I have a couple ideas on how we could get around this though. Ironically, the artifacting is due to the original textures being dds (compressed). If squad never added the dds loader they'd look better
  15. rbray89
    I can't reproduce this. I believe it is due to the garbage collector doing its thing. Sounds like you are hitting the memory limit due to stock mem leak.
  16. rbray89
    I sent you a message for a full fix for odd deformations. You should be able to merge it to your master from the commit. https://github.com/rbray89/KerbalKrashSystem/commit/52cc3a549d29b2bec108bed58e6112888e7c36d2
  17. rbray89
    Ah... so it's the normalmaps? what format are they in (PNG?TGA?DDS?)
  18. rbray89
    Kopernicus only loads body textures on demand. This is for parts.
  19. rbray89
    I can't replicate this. Try deleting the cache folders in C:\Users\rbray\Documents\ksp\ksp-x86-1-0-5\GameData\DynamicTextureLoader\Plugins I can't replicate this. Try deleting the cache folders in C:\Users\rbray\Documents\ksp\ksp-x86-1-0-5\GameData\DynamicTextureLoader\Plugins I can't replicate this. Try deleting the cache folders in C:\Users\rbray\Documents\ksp\ksp-x86-1-0-5\GameData\DynamicTextureLoader\Plugins
  20. rbray89
    This should provide the best deformations yet: https://github.com/rbray89/KerbalKrashSystem/blob/master/Source/KerbalKrashSystem/KerbalKrashGlobal.cs It should be a lot faster (transforms contact points and distances rather than vertex) and uses distance from contact point to determine how much to deform, so it looks a lot better too. I gave up on grouping the vertices. The procedural deformations made the grouping pretty much irrelevant.
  21. rbray89
    This is usually caused by the machine running garbage collection and freeing unused resources in the background.
  22. rbray89
    what texture pack?
  23. rbray89
    you should be using MeshFilter[] meshList = part.FindModelComponents<MeshFilter>(); there is a big difference between this and the FindInChild mechanism.
  24. rbray89
    Hmmm... It shouldn't do anything like this... I'll have to look into it.
  25. rbray89
    Yeah I saw this in your recent upload. I was going to mention that it wouldn't quite work... the easiest way would be to iterate over the part.partInfo.partPrefab and reset all the vertices.
×
×
  • Create New...