The goal is to simulate the explosion of the building. Currently developing a simulator to Unity 3D. However, now in the time of the explosion, at 4000 colliders fragments building FPS drops to 0.
Impression that unity3d can not provide the necessary performance.
Are there alternatives to the optimal physical calculation and a sufficient level of graphics (lighting, explosion sprites, textures etc)?
4000 colliders is excessive, specially if all start colliding at the same time. You can always optimize and "fake" things. Depending on the scope of your simulation you might not need all generated particles to collide. For example, dust and tiny particles could be voxels.
If your simulation is calculation heavy, which any Physics simulation should be, then you should delegate the number crunching to C.
In Unity you can also take advantage of the shader language and send packages to the GPU to help you render. You should also look for ways to optimize, such as caching Components. Good read on optimization in Unity.
You can also tell your simulation to ignore certain collisions between certain objects, such as, ignore collision between A and B.
Once you hit the ground or a certain condition you could also add this line of code:
rigidbody.isKinematic = true;
That will make Unity ignore Physics for that Rigibody. Info here.
Related
So here is the deal, i have an enemy that is rigged and consists out of quite a few voxels.
When i run the game i get very bad performance overall when its rendering the model because of the amount of objects it needs to render. How can i improve that?
Here's the things i have thought about:
Only rendering the faces we actually can see,
Or maybe using some sort of GPU Instancing?
Anyways, i would like to know how i could resolve such a problem. Any help is much appreciated!
Without knowing how you've actually implemented your voxels in game (i.e what components each voxel consists of and how you're currently managing them) it's hard to offer much specific advice.
In general though there are a few things to consider:
Faces that aren't oriented towards the camera won't be
rendered by default. What you might want to investigate is
Occlusion
Culling, but
since your character is not static within the scene you might not get
much performance improvement from that. The code to
constantly check whether objects are occluded might end up costing
more CPU than not implementing it.
Rendering might not be your actual bottleneck for performance. If each of your voxels is doing some work every update (such as collision detection), then that's going to hit your performance much harder than rendering the objects, particularly for cubic voxels. You'll need to use the Profiler to figure that out.
You need to consider whether you actually REALLY need all those voxels to be in the scene all the time or whether you can replace them with a single GameObject until you need to interact with them, then bring them into the scene as needed. For example, you might replace the upper arm with a mesh that mirrors the shape of the total voxels for that body part. Then when that part is shot, for example, you can detect the point of collision and instantiate the necessary voxels around that point to react as desired, then rebuild the arm mesh to reflect the changed shape.
It might also be worth looking into Unity's Data-oriented Technology Stack (DOTS) features, although that could be overkill for this situation.
I have been building a game for VR using Unity3d. It has only low poly models and the file size is less then 40 mb still the game lags when played on mobile.. Please suggest how to improve the performance..
Thank you in advance..
In order to improve performance in VR for mobile you have to optimize everything as best as you can, you should keep some of these variables in mind:
Graphics Side
- Number of polygons in the scene
- How many source of lighting do you have
Programming Side
- How much work is taking your code, is doing it efficiently?
The programming part can include problems within the physics system, also some logic problems that can probably decrease the overall performance because of higher computation.
My advice is to learn about the Profiler that unity offers, actually you can observe how much work is taking your code and where exactly it is your bottle-neck. This video also can be useful.
Of course a solution could be implement your code following design standards, like design patterns and software architecture (depending on the size of the project).
I hope it can be useful for you!
What I found from developing and launching a vr game is some of the issues below
Number of polygons is usually your first to check even though your models are low poly. For example, I looked at Synty models in the unity store and some of them were over 1k for a bag and 7k for a character model. This seriously reduce the amount of objects you can if you want to target a max of 50000 per eyes.
With some models, you can use blender and the decimate tool to reduce the polygon count pretty easily. From there I would use LOD's to reduce their count further based on distance.
Use occlusion culling (pro version only)
Set your camera distance to maybe a 100 instead of the default
Use mobile shaders and careful using some of the standard shaders as they are expensive. Also transparent shaders will becomes expensive cause overdraw.
Batch your textures and make them static if possible
Don't use dynamic shadows on lighting but instead bake your lights
Try to avoid using physics as this becomes expensive and instead raycast to trigger events or shooting weapons.
Run profiler often and check for any bottlenecks (pro version only)
Reduce the count of Particles effects and their values
Character bones can also cause issue so remove as many as possible
There is also your code to look at as mentioned by Manujamming
Set quality setting to low in the inspector to gain best performance.
Could you provide a screenshot of your game scene?
I hope this makes sense.
Best of luck!
So, I'm working on a game and I've run in to the problem that.. I'm trying to detect the collision of two objects, and at first I assumed I needed two colliders. Then I found out I needed a rigid body, now I've come to find both object need a rigid body and this is a lot of cpu usage and the rigid bodies serve only to detect these collisions. It vastly limits how many objects I can have in a scene.
The only solution I can thin of is to be cast small rays from each side. Are there any other industry standard solutions that are more optimal?
Thanks in advance
There's no way to do exactly what you want. As you did not describe what you are planning to do (not even if 2D or 3D), here's a generic solution:
1) Attach a Rigidbody to only to one of the objects (out of two which could collide)
2) Tick in IsKinematic on Rigidbodyso it won't react on Physics
3) Tick in isTrigger on the other object's Collider (so it won't need a Rigidbody yet fires away trigger events when hits another object with a non-trigger(!!!) collider (and a Rigidbody)
(Or use Rigidbody on all your GOs, yet tick in IsKinematic on all of them)
As of your own collision detection, see #Hellium's comment.
I would add that, if you code your own collision detection, at the end of the day you'll most probably end up with a code eating more calc. time (and probably being at least a bit more sloppy).
Simply because you'll code in script, not C++ and the engine's Collision Detection is C++. (Your .net script will compile to native via il2cpp, so not a native implementation == must be slower than the code having similar nature, yet supported by the engine, i.e. coded in c++)
Side note: If you find your app. running slow, that's not necessarily because of collision detection. It's not impossible it's your code, what you do when you detect collision is running slow.
I highly recommend using the profiler to see what slows things down in your application.
If it really is your code, post a question on how to make that run faster.
I want to create an explosion particle system, but I'm not sure how can I do it. I was thinking create a fire particle system with emitter shape being an Sphere and after that just increasing sphere radius, but I don't know how can I animate it's size. Does anyone tell me how can I do that? Or does anyone have a better idea?
Emitter systems for particles are setting initial particle directions, and the rate they'll move at. That's generally how a visual representation of an explosion is created.
So rather than increasing the size of the emitter source to present an explosion, the dissemination of the particles in an outward direction creates the appearance of an explosion.
You're not limited to one batch of particles, nor one type of particles, nor just one emitter. The best explosions are a highly complex layering of different particle types with different textures, coming from different emitters at differing rates, with differing rates of decay, spin rates, colour changes and falloff in both transparency and movement speed.
Making a truly great looking explosion is a real art form and will often take a good designer days to do with a GUI and constant real time playback, especially when trying to minimise the use of textures, quads, blends, fillrate and physics.
Here's a video from Unreal Engine, wherein similar concepts and qualities as what's available in Scene Kit are used to teach the terminology. It's not a 1:1 parallel with the Scene Kit particle engine, but it's probably the best combination of visuals and simplistic explanations to help you rapidly understand what is possible and how to do it with particles.
//caveat: Unreal Engine probably has the best real time particle engine in the world at the moment, so it's a little more advanced than what's in Scene Kit.
But...the principles are essentially the same:
https://www.youtube.com/watch?v=OXK2Xbd7D9w
I read that using a physics engine can be the cause of many problems in programming platformer type of games.
I am making something similar to the platformer game(not a classic platformer).
Game will have a platforms, but not many.
Game will not have moving platforms
Game will not have slopes
Game will have ladders
Hero can shoot the enemies
Hero can jump
Hero can access ladders from the air
I have to choose between physics engine and tile tehnique...
The first problems I can think of are:
problem with physics engine and the ladders because physics rules are applied to hero and his movement,so I guess it would be hard to get him on the ladders while his physicsBody.dynamic property is set to YES.
problem with the tile tehnique - how to make hero falling from the ledge(while running) with an realistic arc (when we use physics this is done by engine itself...)?
And the main problem, based on the type of the game I am making, is, sholud I combine tiles tehinque(let's say for hero's moving) and physics engine for collision detection, and shooting enemies?
I know there are a lot of questions about this subject, but I must start from something...
Tnx in advance
I would recommend the physics engine. It is very straight forward... what you expect is generally what happens.
Run, Jump, Shoot, Fall, etc. - Very easy to do using the physics engine.
Ladders will be problematic but you could set a bool flag that lets you know when the ladder and hero are touching, therefore allowing you to exhibit different behaviors depending if this bool is true or not. Ex. Make hero not affected by gravity if touching a ladder.
It is very smart that you are planning this out ahead of time and have outlined all of your core requirements. IMHO, the rest of the requirements will be so easy using the physics engine that it will outweigh additional time spent on the harder part with ladders.
I would advise against using a physics engine unless you have some complex physical interactions that would be difficult to code by hand, i.e. not just collision detection and basic movement but things reacting realistically to collisions, mechanical objects made of many moving parts and joints, etc. I'm not sure what you mean by a "tile technique", but you can easily code by hand things like a character accelerating towards the ground while maintaining forward momentum (i.e. tracing an arc).