UPDATE: the problem was in floor size. I just made it smaller and problem is solved.
Hello there, I spent almost 1 week already googling... hope that you can help me with that. I baked my shadows, result and all needed settings are shown on the picture. The problem is that quality of shadow on the tree is much much better than of shadow on the ground. Do you have any guesses why?
I just made this one tree bigger than others so that it's easy to see the problem...
(shadow quality is set as the highest, rendering path is Deffered lightning)
Reducing the size of the ground object solved the issue.
The likely reason this works is that texel budget per object is limited by the lightmap size regardless of user-defined texels per unit. For example, if lightmaps are 2048x2048 and the ground is 2x2 km, there is ~1 pixel per square meter, assuming 1 unit is 1 meter.
Although it was not the case here, inconsistencies between shadows may be observed when dynamic and static shadows use inconsistent resolutions.
Related
I have this simple domino scene where you can click a domino and apply a force to knock it.
At first I had this dominoes in a scale of (x=0.1), (y=0.6), (z=0.3) 1 is supposed to be 1 meter, they fell without a problem but too slow. According to unity documentation on Rigidbody this made total sense.
Use the right size.
The size of the your GameObject’s mesh is much more important than the mass of the Rigidbody. If you find that your Rigidbody is not behaving exactly how you expect - it moves slowly, floats, or doesn’t collide correctly - consider adjusting the scale of your mesh asset. Unity’s default unit scale is 1 unit = 1 meter, so the scale of your imported mesh is maintained, and applied to physics calculations. For example, a crumbling skyscraper is going to fall apart very differently than a tower made of toy blocks, so objects of different sizes should be modeled to accurate scale.
So I just re sized the dominoes to (x=0.01), (y=0.06), (z=0.03), this time they fell to the desired speed but for some reason they stop falling and don't knock the next domino.
example GIF
I don't know why this is happening but i can guess that this is because at the time of calculating physics the engine doesn't waste so much resources in calculating small objects that are probably not even going to be seen by the user.
Modifying mass doesn't seem to do anything, also draw and angular draw are both 0 and already tried every collision detection mode.
Is there any solution or workaround for this?
In my experience, Unity physics doesn't like too small objects since it introduces rounding errors. A game simulation usually does not need the same accuracy as when you try to land on Mars. Therefore, I usually avoid scales less than 0.1f.
In your case, I would keep the scales at 1.0f and instead experiment with either increasing the world gravitation, changing it from the default -9.81f to -98.1f (Edit - Project Settings - Physics). Or changing the default Time Scale from 1f to 5f (Edit - Project Settings - Time).
Try not to make too big changes in the beginning since it might introduce strange effects on other parts of the gameplay.
I have a situation where I have loads of high-resolution bushes.
The issue is, these bushes are far too high detail and thus cause performance issues (partly because of shadows). A smooth solution to this would possibly be mipmaps, allowing the bushes to become lower resolution when further away from the camera. However, this did not work as anticipated.
Scene with mipmaps (as you can see the sprites further away are blurry):
Scene without mipmaps:
This is the performance difference.
With mipmaps
Without mipmaps
Why is there no performance increase?
Your mipmaps are not the solution for your performance issue. They only reduce the texture resolution of the objects further away. The performance difference is there, but it is not what you expected.
737 Batches is alot of draw calls batched together.
To reduce the draw calls and to gain the desired performance boost
you have several options:
Reduce the Triangle Count. You did not show the wireframe as suggested, but what you want to do for your grass is have a simple square with 2 triangles and use the alpha mask based texture like you already did.
Make your material more efficient: for example do not use 2 sided rendering, if you use a shader graph, reduce the amount of processing.
Make them grass objects static and bake your lighting. as the renderer will need 1 draw call for the mesh and 1 draw call for the light, this will drastically reduce your draw calls.
Additionally, you could also group several grass objects into clusters. Texture them with one material, as each individual material also efeccts your performance.
To understand the difference between draw calls and batches, read this:
https://support.unity.com/hc/en-us/articles/207061413-Why-are-my-batches-draw-calls-so-high-What-does-that-mean-
Very informative forum post on polycount where Joe Wilson shares some knowledge. Worth a read:
https://polycount.com/discussion/206507/the-cost-of-a-texture-draw-call-quantity-vs-resolution
TL;DR : I want to find a method to give an impulse to an object so that the speed of this object is precisely proportional to the scene size.
I am currently building a SpriteKit game that will be available on many different screen sizes, my scene resizes itself to be the same size in points as its view (scene.scaleMode = .ResizeFill), when I launched my game on other devices than the one which I had developed it, I noticed that :
The size of nodes was too small
The speed of the objects was too low (the way I give speed to my objects is by calling applyImpulse(:_) on their physics body).
I think I fixed the size issue with a simple proportionality operation : I looked at the objectArea/sceneArea ratio of the scene that had the correct object size and than, instead of giving fixed dimensions to my objects, I simply gave them dimensions so that the ratio is always the same regardless of the scene area.
For the object speed, it was trickier...
I first thought it was due to the physics body mass being higher since the object itself was bigger, but since I attributed to objects their mass directly via their mass property, the objects would have the exact same mass regardless of their size.
I finally figured out that it was just due to the screen size being different therefore, an object, even by moving at the same speed, would seem to move slower on a bigger screen.
My problem is that I don't know exactly how to tune the strength of my impulse so that it is consistent across different scene sizes, my current approach is this one :
force = sqrt(area) * k
Where k is also a proportionality coefficient, I couldn't do the proportionality on the area, otherwise, speed would have grown exponentially (so I did it with the square root of the area instead).
While this approach works, I only found this way of calculating it with my intuition. While I know that objects areas are correctly proportional to the scene size, I can't really know if the speed can be considered as equivalent on all screen sizes
Do you know what I should do to ensure that the speed will always be equivalent on all devices ?
Don't do it
Changing the physics world in relation of the screen of the device is wrong.
The physics world should be absolutely agnostic about its graphics representation. And definitively it should have the same properties (size, mass, distance, ...) regardless of the screen.
I understand you don't want the scene to be smaller of the screen when the game runs on a iPad Pro instead of an iPhone 5 but you need to solve this problem in another way.
I suggest you to try another scaleMode like aspectFill (capitalized if you're on Xcode 7: AspectFill). This way the scene is zoomed and all your sprites will appear bigger.
Another point of view
In the comments below #Knight0fDragon pointed out some scenarios where you might actually want to make some properties of the Physics World depending on the UI. I suggest the reader of this answer to take a look at the comments below for a point of view different from mine.
So, I'm attempting to create a simple dynamic endless terrain using simplex noise.
So far I've got the noise working just fine - however I am having issues with the terrain having discontinuities at the edges. At first I thought this was due to the fact that I was not calling SetNeighbors on the Terrain objects, but adding this did not seem to yield any improvement.
terrain.GetComponent<Terrain>().SetNeighbors(left, top, right, bottom);
This problem seems to be caused by the slight differences in height between each terrain position - but making these set the same will effect the terrain quality (will reduce how jagged the terrain can be in certain cases) and generally seems inelegant. I've been going through the unity docs trying to find how to address this, but have yet to find anything.
Is there something I'm missing? Or is my only option to fiddle the heights on one of the sides to match the other?
Thanks for reading, appreciated as always.
Terrain image for reference
A couple things-
First, make sure you're setting SetNeighbors() on ALL the terrain objects, not just one.
Secondly, if the terrain don't match up exactly, it either means that the terrains aren't calculating their data quite correctly, or there's some floating point error going on. However, I have a suspicion that it's the first one, given that manually changing the points affects the quality. Make sure you know that terrains have n^2 + 1 points, and also make sure that the point to query from your simplex function with is calculated in world space.
If you can't figure it out, post your code and I'll take a look.
Also, your terrain might look better if you used octaved (a.k.a factal) noise on your Simplex noise function, depending on what you're looking for.
Cheers!
Surprisingly I couldn't find any meaty info about this, so here I am.
I understand that 1 unit in the editor = 1 meter, but does large worlds affect performance? I mean, they obviously do in sandbox games and other games packed with content. But what if it's mostly empty? My current project is a 2D Gravity Wars clone game with moving planets. Should I make it as small and condensed as possible, or is there room to scale things up?
Basically, do large distances in a mostly empty world affect in-game performance?
Simple answer ... No.
The only thing you lose with big numbers when we are talking about float based vectors is precision.
So the real question becomes ... how accurate do you want your logic to be?
I tend to build stuff placing verts on round value points then scale for size rather than space vertex info at scaled points ... if that makes sense / helps?