rbray89

Just sent you a PM. I haven't seen the texTile function before... are you sure it isn't shipped with the proland stuff? It isn't a standard cg call, and I don't think it is from the unity cg include. If I had to guess, given that it is using the _Normals, I would say it is getting the normal values (rg) from the normal map.

Small update, added lighting to atmosphere. Still has the "apply" bug.

Ah... I had been thinking about this recently... With cubic-texturing, this can be an issue as you have found. The single-texture all-way tiling is tricky to implement on a texture, and on top of that, it doesn't work well if you want specific detail. I had thought about allowing the different axis to tile different textures. Would this work for you?

In my WIP release, shadows are generated using a projector, so they actually affect terrain.

Known issue: "The box issue is from some unknown occurrence that I have yet to figure out. Re-apply the layers (alt+e, hit "apply") after you load a vessel and you should be good. Seems to re-set if you go back to the space center."

Soooo many things I want to do. So little time

The DDS Loader squad implements makes all textures unreadable, so the main texture must be PNG (or ATM must be used) to ensure it will load as readable for volumetric clouds.

Oh, and it seems the only shader that needs replacing is terrain (and possibly ocean if that is how you are doing things) all other shaders are writing to the depth buffer now

There is no difference in the x86 and x64 binaries anymore, so I only build "x86"... So have at it

Yup! just navigate the GUI to the ocean settings. There you should find color and depth settings.

Everything on my end could be removed/altered with a config change I'll probably end up shipping with two zip files: "stock" clouds+atmo pack, and plugins.

That it does I have to re-map it at some point, but for testing it works.

The box issue is from some unknown occurrence that I have yet to figure out. Re-apply the layers (alt+e, hit "apply") after you load a vessel and you should be good. Seems to re-set if you go back to the space center. Not yet, but it is one of the many things I want to address. ALT+E and mess with atmosphere parameters I'll post a guide or video when I get everything setup. Does this *only* happen with OpenGL? Does it go away if you use ALT+E and hit apply?

Updated for 1.02.

Those are odd issues... I'll have to look into them. There is at least one issue I know of that occurs when you load a vessel. You have to hit apply before anything will work properly.

Cool! So... I *THINK* the atmosphere that I have implemented has the right amount of haze now. It is also VERY configurable. pretty much endlessly configurable. I just have to add light and color handling now. Let me know what you think!

Alrighty, so I uploaded another version for dev testing... I think I have the atmospheric haze down. Now to add light and color. There is still an odd issue that got introduced with 1.0 that makes it so the clouds have to be re-applied in flight. So if you want to try this out, load a vessel, then hit alt+e and hit apply. You can then close the GUI with alt+e

I think both Blackrack and I have to rebase our shaders off the KSP ones. This might be causing the issue seen.

had to dig around a bit, but found the guide I used here: http://forum.kerbalspaceprogram.com/entries/1265-An-Adventure-in-Plugin-Coding-7-Thanks-for-the-Persistence

My guess is that the new shaders from KSP haven't been pulled, so when we run shader replacement, it breaks new shader features Squad added between updates. - - - Updated - - - Hmmm... I never thought about that one. You could manually populate the entries, or you could split the config items into sub-classes and load them individually. Keep in-mind, the configs are organized not by file, but by config node.

The KSP implementation is great. You use attribute tags ( [persistent] ) for flagging members in a class. Then you can use the KSP config load to instantiate the class from the config file. Works really well.

Don't think that works... Pretty sure it should be localToWorld.Inverse()*cameraToWorld. Remember that the order is inverted for matrix multiplication. Also, I'd probably convert the oceanToLocal to oceanToWorld rather than the change the camera matrix so you don't have to perform an inverse matrix calculation.

I hope so too! I really want to see those oceans!

this doesn't seem right: Looks like you need a cameraToLocal or WorldToOcean instead. // compute ctoo = cameraToOcean transform // also should be correct Matrix4x4d cameraToOcean = localToOcean * cameraToWorld; - - - Updated - - - Oh... Once you get everything working, reference shader params by their ID, not their name. Otherwise it has to do string lookups, and can add a good bit of processing time.

Yeah, those vertex's are annoying. I tried (unsuccessfully) to rid myself of the geometry but couldn't. I think in 1.0 there has been some serious optimization though. I'd have to check, but I am almost certain that the ocean has been overhauled to reduce vertex count.