Fly-through camera path still buggy on some devices

[wp9015362]

Hello,

as far as I can see, @tigrouind apparently has provided some improvements for the fly-through camera:

https://github.com/phoboslab/wipeout/commits/master

But the fly-through camera path is still buggy.

The camera still goes out of the track or under the track and so on...

The funny thing though is:

On some devices it seems to work better than on others.

For example:

The camera path seems to be better on an Android smartphone running Mozilla Firefox for Android 37.0.2 than on a desktop PC running Mozilla Firefox for Windows 37.0.2.

I don't know why there is a difference, even though both are using up-to-date versions of Firefox. But the camera path definitely seems to be better on the Android smartphone.

Would there be any chance you could improve it?

PS:

Tested using: http://phoboslab.org/wipeout/

Regards

[tigrouind]

I already notified this problem. This happen on devices running the viewer with a low framerate (< 60fps). The camera seems to always "lag" behind the track, and keep colliding with track polygons.

To be confirmed : this is because camera path is smoothed using some interpolation / damping https://github.com/phoboslab/wipeout/blob/master/wipeout.js#L74. This interpolation seems to be framerate dependent.

Updating the camera using fixed time step (so that rendering time does not affect the way camera is updated ) should fix the issue.

[wp9015362]

@tigrouind wrote:

I already notified this problem. This happen on devices running the viewer with a low framerate (< 60fps).

Yes, I can confirm that the issue gets worse with lower framerates.

And unfortunately the overall framerate is not that good, as reported in:

https://github.com/phoboslab/wipeout/issues/18

@tigrouind wrote:

Updating the camera using fixed time step (so that rendering time does not affect the way camera is updated ) should fix the issue.

It would be nice if you could also have a look at this while being at it:

https://github.com/phoboslab/wipeout/issues/3

Regards

[tigrouind]

I made a fix (to be checked on mobile) https://github.com/tigrouind/wipeout/commit/6e96e298ad52ae514221c950ab53ef0ad131967a

wp9015362 : could you pull out that change and test ?

[wp9015362]

@tigrouind :

I can only test using:

http://phoboslab.org/wipeout/

So, maybe you could make a pull request for:

https://github.com/phoboslab/wipeout

so that @phoboslab can merge it and make it go live in http://phoboslab.org/wipeout/ ?

Regards

[aybe]

I confirm this is fixed (HTC 8X), but since the additions of these animated bonuses the overall simulation is way slower !

[tigrouind]

@aybe by "animated bonuses" do you mean the weapon tiles ("X" sign) ?

If yes, could you try the following versions on your mobile :

f5163c583dfe2848a236a2f250746505160135cb (no weapon tile animation) 33a3e63b8d6cd738e236b7790ace56ac58666a5b (weapon tile using custom shader) 9108da13b6bcec567c4ca55e467e15c3dbd9c756 (weapon tile using MeshBasicMaterial)

is there a performance difference?

[aybe]

yes a bit, it'll never be smooth however. This IE10 browser is quite bad so I don't expect any huge improvement.

[tigrouind]

@aybe : could you please try the following : https://github.com/phoboslab/wipeout/blob/master/wipeout.js#L32 change 2048576 to 50000 (this will reduce camera far plane and because of frustrum culling, increase performance)

[aybe]

It is way better, nearing 20+fps and almost convincing while before it was like a 486 running a Pentium game :boom:

So :clap: :muscle: :+1: , one regression though : it takes way longer to load and scene is frozen during that time.

EDIT: yes by animated I mean bonus/speed tiles

[aybe]

@wp9015362 you can easily test those releases by doing the following: (need a PC with WIFI and your phone needs to be connected to it)

• grab that commit, unzip it and copy game data to folders
• put the free Mongoose web server at root and launch it

There's a trick though:

If you have something like VMware which adds network cards, the server might run on the wrong interface, either disable them or change their order like below: (don't forget to kill/run the server again on the tray bar)

If you can't see item 2 just press Alt+N.

[wp9015362]

@tigrouind :

You seem to have misinterpreted my first post.

It's actually not the smartphone that's making the issues. It's the PC.

The PC (Intel Bay Trail system with integrated GPU) produces a much lower framerate than the smartphone (Qualcomm Snapdragon 800), which I have also reported over there:

https://github.com/phoboslab/wipeout/issues/18

The Qualcomm Snapdragon 800 powered smartphone is running the viewer with almost solid 60 fps @ 1920x1080.

On the Intel Bay Trail PC though, the performance is quite bad @ 1920x1080.

But I can't exactly tell how many fps it is.

So, it would be nice if you could add a FPS (frames per second) counter to the viewer, just like requested over there:

https://github.com/phoboslab/wipeout/issues/2

So that it would be possible to see with how much fps the viewer is running.

Anyway, I don't really want to install a webserver to test this :wink:.

Maybe you and/or @phoboslab could host a development version of the viewer and give it a URL like for example:

http://phoboslab.org/wipeout/dev/

or something like that where users could test development (pre-release) builds of the viewer?

That would make it much easier to test development builds.

Regards

[phoboslab]

So, what's the ultimate goal of this project? If we want an accurate viewer for wipEout/WipeoutXL models and tracks and document the data formats used by these games, the path is pretty much clear. I consider the latter especially important, so that this project can be the foundation for other ones.

Improving performance implies adding complexity by merging models, baking texture atlases, reducing draw calls and maybe introduce some sort occlusion culling. Adding complexity implies less understandable code, which hinders the documentation.

I always considered the fly through as a "gimmick". It's nice to have for nostalgia's sake, no question, but do we really gain anything by making sure it runs fine on mobile hardware?

tl;dr: I don't care much about performance improvements. In fact, I'm against it, if it turns out to be complicated.

[aybe]

@wp9015362 IMO there's not much point in expecting in a dev URL for a few reasons:

• cumbersome to setup (rough guess)
• how it is going to pick forks commits ? because that's where new things are put in test, refer to no. 1

Hence my instructions on how to test quickly on your side.

An IGP means what it means after all, it's a low end GPU... an FPS counter wouldn't help much, you already know it's not solid 60FPS.

[aybe]

@phoboslab I agree, such clarity really helped me out in understand the formats quickly and I'm soon to reach your experiment level of features because the code is really easy to understand. Not sure what your goals are, you've already provided great foundations regarding this game's internals.

Things of interest I would like to see added are the missing ones from the original game, once they've been figured out... In this regard I hope that my C# project of a more technically inclined object viewer will help, with a vertex/polygon picker allowing a precise examination of the scene.

I am about to reach 1:1 concordance with your experiment, then later, hopefully I'll be able to unveil more of the game's internals.

[wp9015362]

@aybe wrote:

An IGP means what it means after all, it's a low end GPU... an FPS counter wouldn't help much, you already know it's not solid 60FPS.

Well, I am not the one who began complaining about performance in this ticket and not the one who began talking about specific framerates in this ticket :wink:.

I actually created separate tickets for those issues, see:

https://github.com/phoboslab/wipeout/issues/2 https://github.com/phoboslab/wipeout/issues/18

:wink:

@phoboslab wrote:

I always considered the fly through as a "gimmick". It's nice to have for nostalgia's sake, no question, but do we really gain anything by making sure it runs fine on mobile hardware?

Sorry, but at the moment I am actually considering the free camera as a gimmick, since it currently has such bad controls, as reported in:

https://github.com/phoboslab/wipeout/issues/7

@phoboslab wrote:

I don't care much about performance improvements. In fact, I'm against it, if it turns out to be complicated.

Then could you please at least merge the two commits from the following pull request:

https://github.com/phoboslab/wipeout/pull/16

?

:wink:

Regards

[phoboslab]

@wp9015362 I'm sorry, I didn't mean to come of offensive.

The buggy camera path on some devices is a result of performance problems. I'm just asking if it's worth fixing these issues if it complicates the project much and makes the code harder to understand.

Honestly, I didn't think much about what the goal of this project should be when I first created it. Now, after having put some thought into it, I believe documenting the data formats with as much clarity as possible is the most important thing. A "full featured" fly through animation, with better performance, some ships on the track, fullscreen, motion blur and whatnot would certainly be a nice fork of this project.

I'll merge the pull request as soon as I've figured out how to handle this part a bit more elegantly. Later today, hopefully!

[phoboslab]

Fixed in https://github.com/phoboslab/wipeout/pull/16