Simulation speed changes for unkown reason

[Marc]

Ok, then I'll flip the sign of one and rotate & move the the terrain accordingly. I'ld also have to mirror the grid, unless you'ld add some option to flip the interpretation of the grid ... maybe? I use the current layout for other things as well. I'ld have to hold a mirrored copy in memory otherwise. :/ [edit]Idea: Is the vertical scale parameter of NewtonCreateHeightFieldCollision() allowed to be negative? That would flip the representation as well while not flipping the triangle orientation.[/edit]

I always had confidence in your engine for a few years already. The reason I didn't use treecollision but opcode instead was because of the rebuilding time of the treecollisions back then in 1.32 or 1.53. Since I didn't know about MakeUnique, or maybe that even didn't existed back then, I used opcode through a usercollision. That way I could recreate a newtonworld faster for my rewinding etc. I will happily change that since these limitations seem to be not true anymore.

I thing related to the newtonheightfield: In my debugvisualization, I also query the bounding box with NewtonBodyGetAABB(). I see that max y is limited according to the "heighest" point in the heightfield, while the min y is just 0. Is this intentional? My heightfield values are in the middle of the possible value range, so I noticed. There is another thread in the forums talking about dynamically changing the heightfield. Maybe raising it might not always succeed that way if you raise it outside the bounding box? Just guessing.

I saw a few discussions between you and others working on physic engines. I'm not entirely sure what caused the trouble. I just know that your engine is really stable, fast, reliable and easy to use compared to others I've tried. And the support is superb I also know about this general problem you mentioned earlier that people say things they just believe instead of knowing for sure - or - just saying something even though they know it's not true just to look competent to others that also don't know what they are talking about. And on the internet, it's particularly complicated to distinguish those people from those who actually know what they are doing. But this is a general problem that exists everywhere I guess.

[Marc]

I have to go now though. It's 12:27 am again over here. Happy AABB-Triangle-check-implementing to you Cya tomorrow.

[Julio Jerez]

Ok I have the optimization done and I test it the demo that still have the user define Mesh.
and It is a concrete 300% faster.
The Highest spike is ways lower than the first Bar, and before it was always over the third Bar.

I still to do get 60 fps, I am getting 52-54
So I update to see if you check it the new code that use the Newton HeightField by you have not done yet. Because I still see the same spike pattern.
My guess is that when you test it now the physics will become and no issue, for the game.
Cross my fingers Nock in the wood.

Anyway I uploaded the New Beta 2.08
Could you try that and let me know?

[Julio Jerez]

Wow I played a litle more an dwhen I start and I instrut the untis to move the go fast now,
I support this is how they are support to behave.

The FPS in 59 and some time dip to 54, by the physic remain steady with not spikes.
Then I added abuot 40 units N and M in a repeat action and the FPs remain constant, how ever when I select them and ask them to move it dips to 40 fps.
However I do not see the physic Bar being any slower.
It is funny seen so many red and blue units trying to find thier way to a fight, it is like those space invader arcade of the pass

My guess is that when you add the New Hieght Field Terrain and the CollisionTree, the physics time will be so low that you do not have to worry any more and you can focus in the Game.

Youuuuuuuuu don't not Know the Pawaaaaaaaaaaa of the Darkside.
I love this Job

[Marc]

Great! Yes usually they should not slide that much. I made them slide that much when I wanted to show you the difference between the slow motion and the normal way of moving. I will change that again when we are done optimizing. It's more comparable when I don't change behaviour while optimizing physics.

On one of my pc I get around 20fps but on my laptop I already have 60fps. I think it's already more bound by the graphics and not by the physics that much. On the 20fps pc, I only have a 7300 geforce. The faster one is a laptop from about 4 months ago and has some ati card, I don't know exactly which one but not to bad. The cpus are comparable though. And I know things I can/have to do to optimize the rendering. I guess it can run 60fps on the other pc as well.

I'm not entirely sure how to do the final way of fighting, but I never like micromanagement too much so I like the way the kind of fight in a chaotic way so even if you'ld like to do micromanagement of the units, it's probably not helping that much.

You are correct, the opcode collision and the heightfieldusercollision are still in your version. I didn't want to update the exe without you knowing to keep your testing results while optimizing comparable. I will upgrade it - but not right now. It's saturday evening and my gf wants my attention

Thx Julio!

[Julio Jerez]

if gcc builds are so fast, you could try offering GCC dlls on win32 aswell?

You can find recent MinGW builds with the latest GCC for windows here: http://www.tdragon.net/recentgcc/

I installed this in my system, it is much better than MinGW, at least it is up-to-date, in fact it is even better than the Linux and Mac which still use GCC 4.2 this is GCC 4.4.1

Just to tried I run make of the LINUX make file and it almost compile the entire project with the exception of the Pthread which it cannot figure out because of the DEFINE,
So I guess that after I modify the make file it should build GCC Libraries, if this works I will add them to a Different folder in the window SDK.
The preformance of the GCC build is Linux is not a fluke it is definitely more than double that of the Visual Studio build, and I confirmed this with the Mac Build as well.
GCC outperforms Visual Studio hands down.
So let us see if we can get a CGG Library that car compatible with Visual studio project and are also so fast. Has anyone build libraries with MinGW and link then with Visual Studio projects?

[Marc]

Wow, I tried your new version and it's an incredible speed increase for my physics scene. Inbetween the invalidation spikes it only takes around 3ms to update the scene on my 20fps pc. And the invalidation cache spikes are below 10ms most of the time as well. When I start moving the units, it hardly increases the time. Trying with the bunch of guys from before which created this very noticable jump, you can't see anything in the graph now.

In the pic all those guys are moving around when I took the pic.



I'll update to the new version so you can see/test for yourself.

What about the up-axis selection optimization or the scenecollision? Should we try that?

[Marc]

So let us see if we can get a CGG Library that car compatible with Visual studio project and are also so fast. Has anyone build libraries with MinGW and link then with Visual Studio projects?

I never tried creating a dll/lib with MinGW so link it to something else in VS. But this http://www.mingw.org/wiki/MSVC_and_MinGW_DLLs doesn't look too complicated.

[Marc]

ok, update complete. You can get the current version by running update.

I also disabled the freeze calls in that version and there is the newtonheightfield in it and the opcode user collisions are disabled as well. That's because you can walk through buildings right now ...

[Julio Jerez]

That's because you can walk through buildings right now ...

is the walking thorugh building a bug or you did not make the collision trees for them?

On the Up Vector let us hold on that, the information we were getting was wrong, the BroadPhase was fast but the counter were given teh wrong timing.
As it is now the broaphase together with the force callback is the weakest point in the system, optimizing that even if we get say 3 or 400% witch is very rare
It will not make any major impact on the overall performance.

[Marc]

is the walking thorugh building a bug or you did not make the collision trees for them?

It's the expected behaviour right now because I removed the opcode-usercollisions and haven't put anything else there yet.

[Julio Jerez]

ah Ok,
I just updated and in my machine the highest spike is bellow half the first bar. I guess that now the Ball in your side of the court with the AI and Graphics.

can you make the post with the link to teh MinGW stuff to the topic I open about the GCC for VS, so that I can have he the reference in just one place?

[Marc]

Ok I'll add it there.

Yes, there are other things to be more optimized and implemented at all than physics in my game now. Thx for all the help

[Julio Jerez]

What about the up-axis selection optimization or the scenecollision? Should we try that?

On this the Scene collision will definellyt improve teh Broadphase performance specially when you add more static objects.
But it is like they say, more knows the devil because he is Old than because he is smart, or something like that (lost in translation)
I would leave the Scene collision as the last resource for getting more performance of the phsyics when I need it.
As it is know the Broadpase in not even showing in the profiles,
but if you are a couple of tousand trees I will definetly start to show the effects.

Untill then I would leave it alone.

[Marc]

It has been some time since I posted on this thread. But this belongs here: I made my game public about 1 week ago and now I already have players building massive armies like this:



You can see the units of one player in the front, the blue ones, and monsters everywhere in the back. All newton spheres

While this is nice, it reduces the framerate a lot. So now I have two options: limit the amount of units by whatever rule or increase the physics simulation speed. What do you think on the later part? Anything left to be optimized?

(but it's running nicely deterministic so far )

This is still version 2.12 though. I haven't updated to the newer ones since that version worked for me and I wanted to get it releasable for 2010