Jump to content
  • Advertisement
NoAbsoloops

Would Unique paritcles slow down a physics simulation?

Recommended Posts

Posted (edited)

If each of these particles were each a different type of particle, with slightly different properties, would that greatly effect the speed of the simulation?

Edited by NoAbsoloops

Share this post


Link to post
Share on other sites
Advertisement
29 minutes ago, NoAbsoloops said:

If each of these particles were each a different type of particle, with slightly different properties, would that greatly effect the speed of the simulation?

It actually depends on tons of factors. Having small changes like position and rotation can easily be done with instancing, however having different shaders require different drawcalls.

So you could make a system with small changes that don't have a large impact, however the opposite is also true; it is possible to make a particle system with no visual changes but still affect performance.

 

How would you like them to differ?

Share this post


Link to post
Share on other sites
Posted (edited)

If I understand correctly what shaders are, they are basically the graphic work done to the particle balls to make it visually appealing.
I don't need shaders. It would be nice if there was some type of unified shader that could work with the underlying data associated with each particle.

Different colors would definitely help though.

Each particle would have different repel and pull field sizes. Those can be changing. They also have about 3 other hidden variables that change and can have physical consequence.

Edited by NoAbsoloops

Share this post


Link to post
Share on other sites
5 minutes ago, NoAbsoloops said:

Each particle would have different repel and pull field sizes. Those can be changing. They also have about 3 other hidden variables that change and can have physical consequence.

Those things (repel and pull) should have a minor effect on performance, also something like variable restitution or friction.

But there are exceptions, e.g. large mass ratios. If one particle can have 100 times more mass than another, solvers as shown in the video don't work anymore and you need something better. (Notice that most game physics engines do not support large mass ratios for rigid bodies either.)

 

Share this post


Link to post
Share on other sites
54 minutes ago, NoAbsoloops said:

Each particle would have different repel and pull field sizes. Those can be changing. They also have about 3 other hidden variables that change and can have physical consequence.

Then using a cotree system you could refine this very well. Sphere collisions are amongst the fastest and there is lots of research on making it faster.

54 minutes ago, NoAbsoloops said:

If I understand correctly what shaders are, they are basically the graphic work done to the particle balls to make it visually appealing.

Graphics and Physics are the two main performance killers. Physics can even be considered a graphics element most of the time, only there to make things look more realistic or dynamic.

If you rendered every particle as just a single point and it didn't move you could have billions on screen at a time.

 

So a rough baseline for you to use is the Unreal engine. It can currently do 8 000 000(eight million) bouncing ball GPU particles on a mid range computer. Reaching almost 11 000 000 on a high end game rig.

If you made your own engine you could reach 16 000 000 - 32 000 000 particles; if all it did was make particles with very basic physics. If the particles was just 2D points you could reach hundred millions.

Share this post


Link to post
Share on other sites
Posted (edited)
25 minutes ago, Scouting Ninja said:

Graphics and Physics are the two main performance killers. Physics can even be considered a graphics element most of the time, only there to make things look more .... 

Hey Ninja great response, I was wondering if this also goes for complex stuff as well, I can see how being too literal can make it slower with easier stuff, but couldn’t it make it faster in some of the very complex shader techniques? Just curious thanks :) 

Edited by Bradley Latreille

Share this post


Link to post
Share on other sites
5 minutes ago, Bradley Latreille said:

but couldn’t it make it faster in some of the very complex shader techniques?

It depends on what you mean by "Complex".

The general rule is that less is faster, less data and system complexity means faster performance in most cases. However a lot of these systems that reduce data and system complexity, are "complex" to learn.

So if you meant "complex" shaders, as in using the latest optimized code; then yes you could break the limit a bit. There is new ways to optimize things everyday.

 

The other thing you have to realize is that most systems aren't limited by the software, hardware is just as important if not more so. No matter how good your software is, there will be a limit of what you could do with hardware.

So if I had to give a limit to what I think is possible right now using a gaming PC I would say +/- 84 000 000 spheres on screen at a time. If you could get that many spheres with basic physics, I would say you made a huge breakthrough.

 

Now I want to point out that some of the largest screens right now use: +/- 3840 x 2160. That means: 8 294 400 pixels. Meaning that even a high end screen can't renderer 9 000 000 particles on screen at once. Unreal can already fill most screens with more particles than they can render.

Share this post


Link to post
Share on other sites
27 minutes ago, Scouting Ninja said:
1 hour ago, NoAbsoloops said:

Each particle would have different repel and pull field sizes. Those can be changing. They also have about 3 other hidden variables that change and can have physical consequence.

Then using a cotree system you could refine this very well.

On GPU i would prefer a multiresolution grid over an octree, if you can afford the memory cost (which is why GPU physics often have size limits, e.g. cool fluid but only within a box.)

The multi-grid has the same advantages like a loose octree (which is the requirement of only one pointer per cell), but it will be faster because building trees on GPU is still an issue.

33 minutes ago, Scouting Ninja said:

Physics can even be considered a graphics element most of the time, only there to make things look more realistic or dynamic.

This almost degrades people working at physics, which is harder than graphics. Personally i think it is, or at least it should be the other way around: Create working simulations, and use graphics to visualize them. Graphics are fine if they look realistic, but physics need to be correct because otherwise they won't work or you can't do much with them. If you don't plan to utilize physics as a fundamental building block that's fine. But describing physics as a graphics tool and declaring this as general fact instead personal opinion is just wrong.

Share this post


Link to post
Share on other sites
18 minutes ago, JoeJ said:

This almost degrades people working at physics, which is harder than graphics. 

Yes and no, I think he was just talking more on a hardware level as far as memory and stuff, as there isn't such things in real life physics. :) 

Share this post


Link to post
Share on other sites
Posted (edited)
35 minutes ago, JoeJ said:

This almost degrades people working at physics, which is harder than graphics. Personally i think it is

Why? The art that you see on your screen in a game is the work of a 3D artist that had to spend 3-4 years learning art, A animator who spend 3-4 years learning animation and a graphics programmer who spend 3-4 years learning visual programming.

I believe most physics programmers also spend 3-4 years learning how to code physics. So why would you ever believe that comparing a dedicated professional to another degrades them?

 

35 minutes ago, JoeJ said:

physics need to be correct because otherwise they won't work or you can't do much with them.

This is not true at all. :)

We use dumbed down versions of physics all the time. The newton cradle simulation problem is a good example of this. Computers just don't have the power to simulate accurate physics.

Windows in games aren't liquids, we don't track internal forces, we don't even use accurate collisions shapes.  :)

 

35 minutes ago, JoeJ said:

But describing physics as a graphics tool and declaring this as general fact instead personal opinion is just wrong.

I don't know if you realize this but the physics programmers on a team spend a huge amount of time just doing none gameplay stuff. Creating physics for visual appeal. A lot of there work is like this:  http://box2d.org/files/GDC2012/GDC2012_ErinCatto_Ragdolls.pdf

 

Games rarely use physics as part of calculations, it's too unpredictable and can lead to a very unbalanced game. Damage for example is calculated long before the "hit" is checked. That way you can let weapons decide.

 

I agree with a lot of what you say @JoeJ , but in most games physics is cheated for the purpose of gameplay.

Edited by Scouting Ninja

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!