JPLRepo
-
Posts
3,141 -
Joined
-
Last visited
Content Type
Profiles
Forums
Developer Articles
KSP2 Release Notes
Bug Reports
Article Comments posted by JPLRepo
-
-
5 hours ago, pizzaoverhead said:
@J.Random is wondering why point lights aren't used for the sun, as the sun more closely resembles a point light source than a directional one. The confusion is that KSP uses both point light sources and directional sources to represent the sun, whereas only the directional light was affected by the issue being fixed.
@J.Random : My understanding is that point light sources are used for the sun for planets in scaled space (i.e. when you are far enough away to see that they're round), but when you're on or near the surface in the flight scene, a directional light source lights the terrain and vessel, as it's more accurate in that scenario. You often have both lights at once: Sitting on the launchpad on Kerbin, the launchpad and rocket are lit using a directional light, and the Mun is lit by a point light. @JPLRepo is this reasonably accurate?
Edit: Just reading the Unity light types, would an area or emissive light be more accurate in low sun orbit? Craft there shouldn't have strong shadows as the sunlight is coming from nearly prograde through 180° to retrograde.
No that's what I was saying. I didn't understand the reference to omni lights because the Sun is a directional light. To clarify, there are no other lights representing the sun. Point lights are not used in scaled space to light planets. Point lights are not used to light the Mun at the launchpad. There is a spotlight... sitting on top of the level 3 launchpad tower. pointing at the launchpad.
-
On 6/20/2017 at 10:01 AM, J.Random said:
Why can't you use omni light for Sun? With 64-bit version, you should be able to put it at the proper distance, right?
Dynamic lights (suit lamps, part lights) - why don't they cast shadows?
I'm not sure what you mean by omni? but KSP uses a directional light as the article mentions for the Sun.
Here are the types of lights available in Unity https://docs.unity3d.com/Manual/Lighting.html
64-bit? has nothing but everything to do with floating point precision here when we are talking about the numbers in KSP.
The bottom line is that a32-bit float has a maximum of 6 significant digits of accuracy, and a 64-bit double has a maximum of 15. Both are nowhere near enough when dealing with very large numbers such as Solar scale (or even Kerbin scale), let alone inter-stellar scale.
The point is there is not a lot you can do about floating point precision. Unless you use doubles, but even those have limitations and trade-offs.
As for dynamic lights - I assume your question is why doesn't KSP cast shadows with the Kerbal's lights and the part's lights? This is simply a performance design decision. -
On 6/19/2017 at 8:50 PM, Manwith Noname said:
Oh wow! This looks like some awesome work improving things. Kinda disappointed about the "ticking sun" but it explains why that is used in many games with day night cycles I guess. Interesting.
The ticking sun is fixed for the upcoming patch release.
-
On 6/14/2017 at 0:08 AM, Azimech said:
Gives me an itch every time.
Well as per the KSP Weekly it's been reduced by about half.
-
11 hours ago, HatBat said:
@JPLRepo So glad that the tree shadows were finally sorted out and to hear about future lighting improvements. Could you talk a bit about camera clipping and why it became rather severe a few updates ago? And indeed if there is a possible solution.
Which clipping are you referring to?
The one referred to here: -
9 hours ago, sumghai said:
Great write-up @JPLRepo - I finally understand why the game uses two cameras for rendering scenes.
Any chance the Shader rework that comes with Unity 5.6 will fix the IVA shadow casting issue?
We will have to see what the future holds.
-
On 6/9/2017 at 1:37 AM, Damjan said:
Why use two cameras instead of one?
Because of the way the Z coordinate is rendered in what is called the Z-buffer.
So if you look at the picture imagine there are slices like a sheet of paper between where the camera is and it's far clipping pane.
The amount of "slices" you can have between the near and far clipping pane are relatively fixed by Unity. So the greater the distance between the two then the greater the space between these slices of paper becomes.
This creates other problems such as Z-fighting.
So the two camera system allows a small distance between these Z planes at closer distance to the player. Which gives greater Z-buffer depth and less Z-fighting where it matters the most (closest to the player). -
3 hours ago, rob593 said:
Can't help but disagree with this assessment, Changing the way the sun moves (an important orbital transition) to fix a shadow issue (a relatively unimportant issue) seems like an odd compromise in this game about orbital mechanics, especially since the benefit is only really noticeable on Kerbin and less so in space, having the shadows move incrementally seems worse to me than lower quality smooth transitions since they tend to draw attention as they move, I can't really say I've ever noticed the shadows to be all that bad previously.
Personally I would prefer smooth sunsets and sunrises, watching the Mun eclipse over kerbin, etc to better shadow fidelity, after all I tend to be looking up in this game more than looking down.
That said, I appreciate the work you have put into these issues and this post of course, so thanks
And others will say that the shadows annoyed them to no end and that is more important to them.. There was and is no easy answer. But there is light at the end of the tunnel.
-
52 minutes ago, The Moose In Your House said:
Is this for 1.3?
Yes. all the things discussed above were implemented in 1.3.
-
2 hours ago, Space_Coyote said:
Hello, I got a few editing question about editing terrain. and how you would go about importing it into the Unity Game engine (version 5.,6) I mean, is there a way to do this or is the mTerrain mesh hardcoded into the game and can not be edited? I mean is there a way to edit terrain if you wanted to say edit in roads? I'm just curious as I've been fascinated by this game and have wanted to build some sort of infrastructure system. I mean iis it possible to do this and if so, how?
Space_Coyote
No you can't sorry.
And terrain is procedurally generated.
Also, KSP doesn't use Unity 5.6.11 hours ago, Sharpy said:Now what about other planets?
On Duna these seams are maybe 20cm tall. Death to tiny wheels, but a robust rover with rugged wheels will do just fine.
On Gilly...
<snip pic>
well, you CAN jump over them quite easily, but seriously, the gap is good two meters! And driving into it...
<snip pic>
Can you raise a specific bug report for where you see the terrain issues. Attaching a save to the bug report as well with a vessel right next to them would be extremely helpful as well.
Thanks!
-
On 25 April 2017 at 4:24 AM, cephalo said:
I have a concern as to how this is being fixed. The problems with the runway also exist on general terrain also, so if you fix the runway only, and then fix the planets, the runway will break again because you fixed the planets.
This is a new problem that began with 1.2. These cracks in terrain didn't exist prior to that. Someone mentioned this earlier in the thread, and it was explained as the 'kraken' but that is not the case. There are in fact little rover destroying brick walls in the terrain, and you can see them if you get close. On some planets, (I noticed this on Eve.) you can see the rectangular terrain patches that aren't lining up. These are just like the issues with the runway and likely have the same cause.
I am guessing that there is a tiling issue with the vertex textures. Vertex textures need to overlap by one texel in order to line up, or else the edges need to be blended with each other. This is different than regular textures. Also, this behavior could change on different graphics cards.
You would be pleased to know then that the terrain has been fixed in the pre release, and was explained in the KSP Weekly's as an issue related to floating point changes made in the game engine. vertex overlap had nothing to do with it.
-
Try the Level 1 Runway in the 1.2.9 Pre-Release
-
4 hours ago, drhay53 said:
I'm just curious about something that seems related. Recently I've been driving rovers around kerbin and occasionally I hit a "crack" in the surface similar to this. Most of the time the rover just bounces a little, but occasionally it acts like it just hit a brick wall and explodes. This leads to obsessive quick-saving, and I kind of like just setting the rover on autopilot with mechjeb and doing other stuff (taking care of my 1-year old, for instance).
Are the planet surfaces as a whole subject to the same unity issue raised here? If so, I'm not optimistic about the prospects of that being fixed, based on how hard it sounds currently.
The planet seams are part of the PQS system which is a name given to the system which generates the planet's quads (Sections that make up the surface of the planet).
It has been talked about in the KSP Weekly and we have been working on fixes for this issue. We know the issue stems from a change in Unity but have been unable to identify exactly what Unity changed at this stage.
In the meantime we have several work-arounds that we have been working on and hopefully will find an acceptable one for the next release. -
34 minutes ago, Drew Kerman said:
Does the curvature of Kerbin's surface affect how you have to handle placing the runway pieces? Or is that actually made easier since it's now split into sections for the destructible feature?
No it does not. The Prefabricated runways are one model/object placed in the game world.
-
Fairwell to you Kasper, Good Luck for the future and Thanks for all you have done for this great community.
-
Good Luck for the future Ted. You've done great things for KSP and I'm sure you will continue to do great things where ever the journey takes you next.
-
too slow... third.
Well done Guys. Take a Break... while us modders get all our mods up to speed with 1.1.2. Cheers! -
Can anyone clarify what method this is referring to:
* Add the missing extension method, uncomment the bits that needed it
Enter the Shadows.....
in Developer Articles
Posted
The light source is not far away. It is actually at 0,0,0. But the calculations to calculate the rotation based on the celestial bodies is based on where they actually are.
Because a single directional light has better performance that point lights. And you have to consider the rendering paths forward vs deferred and all the pros vs cons of each.
Dynamic multiple lighting support is not currently planned.