Jump to content

rbray89

Members
  • Posts

    2,719
  • Joined

  • Last visited

Everything posted by rbray89

  1. Yeah, the GUI would be responsible for it. You would just have to be careful with manually editing configs.
  2. What if I made it so that 0-255 values could be imputed and saved, or a color chooser thing was available, but the actual values stored as the 0-1 range?
  3. Updated. Fixed some stuff with the specular ocean params, changed to 0-255 color params.
  4. If anything, it is either: 1) UV derivatives aren't working quite right 2) UV placement isn't working quite right. 3) Texture has anomaly
  5. Actual record while going through the album: ... I ... ... That's ... ... ... ... Wow ... ... How ... ... Wow ... - - - Updated - - - Does this happen at all the gaps? or just the one gap?
  6. That was what I was thinking... Simply that it would be easier to find a color that works via other apps.
  7. So how would everyone feel about colors in the GUI/Configs referencing 0-255 values rather than the 0-1 values?
  8. Yeah, I still have to implement a low/mid/high detail system. It's in the works though I also have an idea to add lots of variety to the terrain (different detail sets for snow/rock/grass/sand). I'm starting to worry that the performance is suffering too much though.
  9. You can remove the pqs.cfg if you have no immediate plans to use clouds on gas giants. So in this case, I would. Then open up the terrain.cfg and alter the Mun reference to either be removed, or replaced with Moon.
  10. If you use RVE\EVE\, you shouldn't be using BoulderCo at all. Delete the directory entirely. In RVE\EVE\, you want to make sure that ALL bodies are replaced or removed that don't exist (eg. Jool/Mun)
  11. Hmmm... First: You need to make sure you don't have any references to any bodies that don't exist. Eg. Jool in pqs.cfg and Mun in terrain.cfg. I think that should solve a lot of errors in your logs. Lets start there.
  12. Sounds good! - - - Updated - - - Yup. The _Color param wasn't being applied to the clouds. It's an easy enough fix to make though. Looks like it somehow got removed between revisions. That being said, it is ALWAYS good to know how to use image manipulation programs
  13. Hmmmm... are you sure your configs are set to "Earth"? I just uploaded another version that should help and try to find the issue. - - - Updated - - - Congrats! You just discovered your first bug! I'll have a fix up later tonight.
  14. Oh! That's fantastic! Yes. That is the plan at any rate. Eventually, low, high, bump, and more.
  15. I think that goes outside the scope of EVE. I don't want EVE to physically modify vertices, just make them prettier. Kopernicus modifications WILL be compatible with EVE as soon as I can figure out what is breaking Good to hear!
  16. Well... it is a bit tricky... You see: 1) City lights require the new terrain shader. No easy way around that yet I'm afraid. Might be able to fudge it in the future. 2) The new ocean shader is a bit different than the KSP one. It is transparent, and has no Fresnel effect. In stock KSP, the terrain is shaded to be blue underneath the ocean once you get to a specific depth. In My implementation, the terrain shades the ocean floor based on distance from the floor to the top of the ocean. That way, it is able to reflect depth much better. It does however mean that the stock terrain can't really be used with it.
×
×
  • Create New...