Jump to content

rbray89

Members
 View Profile  See their activity

  • Posts

    2,719

  • Joined

  • Last visited

 Content Type 

Everything posted by rbray89

  1. rbray89
    As long as the part has a working IVA, all that needs to be done is to mask the main texture with alpha of 1 for fully transparent and 0 for opaque. Then it would be create the config to enable it.
  2. rbray89
    Remove the shadowMaterial node in the clouds.cfg file or uncheck it in the GUI (ALT+0)
  3. rbray89
    Not sure... How did JSI do it? For this, it should just be a texture (that might already be in-place if the alpha is correct) and a tiny config file to enable it.
  4. rbray89
    Yeah, reflections are planned, so you won't need window-shine. The module will be called RealWindows
  5. rbray89
    1) Not from what I've seen 2) It will be managed from EVE configs. No need to bring MM into this. 3) I loose a couple FPS 2-3. 4) Possibly... as it stands though, I use some of the stock IVA generation, so no.
  6. rbray89
    Re-using IVA. should work with pretty much any model with IVA that has a good mask texture.
  7. rbray89
    I think it depends on how it was implemented... The way I'm doing it the hit isn't terrible unless you have a LOT of IVAs.
  8. rbray89
    Thought of something cool... Added it to EVE
  9. rbray89
    Thought of something cool... Added it to EVE
  10. rbray89
    No idea. They should have implemented it in RSS if it is available though.
  11. rbray89
    Possibly... It'd be tough, and nuaj uses this interesting trick similar to the ocean you've been using. It is also closed-source and costs money So I couldn't' distribute it openly.
  12. rbray89
    Close... The issue is z-fighting, but the solutions aren't those you think they are As an easy fix, I could actually adjust the depth test offset (we do this in the cloud shadow already actually, as z fighting is MUCH worse on OpenGL due to the smaller depth buffer). This would have other consequences (mountains showing through at odd locations) but should work. In actuality though, I'd recommend the authors of Kopernicus/RSS look into re-scalling the scaled space environment down further. If I were to disable depth-testing, that would have other unfortunate effects like showing through the other side of the clouds, and showing through the side of other bodies (eg. seeing clouds through Mun)
  13. rbray89
    I've seen this before... Unfortunately it suffers from the same problem almost all approaches have with KSP, and that is that we don't stay in atmosphere. Once you get up high enough, the clouds can't be mapped to something that looks good in orbit. Hmmm... I hope to have the new configs up soon, that will provide a good demo of how to do it with textures.
  14. rbray89
    Seriously it is a stock bug. https://www.reddit.com/r/KerbalSpaceProgram/comments/3ujn0h/black_bar_in_the_tracking_station/
  15. rbray89
    This is a stock bug. You aren't running the latest EVE. This is why you have the bug.
  16. rbray89
    What version are you using? Log files?
  17. rbray89
    Soon! Working on that right now. I'm also working on the combination example to show off.
  18. rbray89
    Use texture replacer instead.
  19. rbray89
    This is probably because z-write is off, and the queue of the effects is much later. You could fix this in one of two ways, increase the queue, or enable z-write.
  20. rbray89
    No... I don't do this. What's the performance hit like? Now that I'm sharing textures between bodies this probably won't help much anyways though. Its the only param in the shadowMaterial. Not exactly... Typically shadows are generated by geometry. However, transparent textures mess this up. Not to mention the mapping of the UV. So transparent objects don't cast shadows usually. To get around this, we use a projector that darkens everything that the cloud coverage maps down to.
  21. rbray89
    Yup! http://www.reallyslick.com/blog/2015/09/making-cubemaps-from-overlapping-photos/ The section about erect2cubic
  22. rbray89
    Not to my knowledge. The GIF looked great though.
  23. rbray89
    Me too... I really liked the effects @RoverDude added. I want to get celestial shadows in place first though I think.
  24. rbray89
    Nope. This is a feature of the new ValueNode! It can be either a node or a value. Value uses the default settings for all the other parameters. I did this to maintain as much backwards compatibility as I could before i made it completely non-backwards compatible. It does mean that you only have to remove the body node, and make some minor changes. My configs took less than a minute to do. Eventually though, yes, The other bodies will re-use the cubemap. Just not at this time.
  25. rbray89
    it's in the dev build, ready for publishing. https://github.com/rbray89/EnvironmentalVisualEnhancements/blob/master/x86-EVE.zip If you are using 4k textures, that would basically be 6 4k textures, so it would be more like 8x12k. The cubemap has all sides in memory, and the sides CAN'T be compressed, so I introduced the alpha-mapping feature, that allows one channel (R/G/B/A) to be used as alpha. That way, we get 3 or 4 ( depending on RGB24/RGBA32) cubemaps per cubemap. This means that for the size, it occupies the same amount that a DXT compressed texture would without alpha mapping. The nice thing about cube-maps though is that they don't concentrate pixels at the poles (better pixel distribution) so lower resolution textures look better. I'm using a 2k texture right now, so that would be 6x4k and it looks a lot better than the 8x4k texture. I'm also not certain, but I think I read something about non-square textures occupying all pixels in the square in memory such that a 2x4 texture is still a 4x4 texture. So if that's the case, this should reduce memory usage a bit as well.
×
×
  • Create New...