2087 replies to this topic

[toxie]

I've tried a few times to understand the physics stepping code, but haven't completely wrapped my head around it yet, it's pretty convoluted. However, it's not true that the physics simulation runs at a fixed frequency: from what I understand so far, the PhysicsSimulateCycle() gets a dtime parameter which is usually 1/100 s, but may be smaller if the game wants to simulate a shorter step to make the physics catch up to the current frame time. Something may be not quite right in that logic. At least it means if you run at >100 fps, you consistently have smaller physics steps than if you ran at, say, 60 fps.

 

Something simple to try would be to force the physics to actually run at a fixed 100 Hz and see if it changes anything for better or worse.

 

The part where dtime is not 1/100 (first exit from while loop) is only there to search for collisions and move the ball forward up to that point in time, so that the ball (in theory and actually also in practice, as it stutters even more when disabling this part) is always animated as smooth as possible. But the displacement is also synched to that dtime and the velocities update is synched to the 100hz.

So i don't know where this difference in simulation could actually happen, as to my understanding the simulation cycles should always be the same (unless one counts floating point precision issues), but just chopped into more parts optionally.

 

But apparently there must be some quirk somewhere in the code and, as you say, its not exactly easy to understand.. :/

[toxie]

About the lightmaps: wouldn't you need a separate lightmap for every object that is affected by a light? Seems like you'd need quite many lightmaps in that case. Deferred shading seems attractive, but as you say, the transparencies... to be honest, I haven't read enough about it.

 

 

One could have one lightmap projected from each light (same principle as shadowmap). We could also bake this completely in world space if necessary ((sparse) voxels), this would also solve the parametrization problem (if in object space) and avoid shadow/light aliasing mostly. And we have the luck of pinball tables having a pretty much fixed size and view perspective, so the voxel resolution can be pretty much hardwired. Maybe thats not even such a bad idea. It would mean one traversal to the voxel of the current pixel/sample to shade, then texture lookups -just- for all the lights that are stored in that voxel -and- are active. This might actually be pretty few in practice.

Precomputation could be done via ray tracing, just using f.e. the Embree engine to trace from the voxels to each light easily. And we would get transparent shadows in the precomputation step 'for free'.

 

Just some stupid ideas..

 

I just fear that we might want to have a huge number of lightsources on a table simultaneously (as in real life), including shadows and all, and want to have insanely large framerates at the same time if possible. So precomputing some stuff might be necessary.

[mukuste]

@Stuttering: What could perhaps help would be having the physics update at 120 Hz, while enabling vsync. This would mean that, as long as your PC is fast enough for 60 fps, you get exactly 2 physics steps per frame and no temporal aliasing.

[toxie]

I also thought of that, too, some time ago and when trying it out the problem was that so many constants and heuristics in the code are hardwired to the 100Hz, that 120Hz changes the actual physics behavior..  :/

So we cannot simply change the steptime unfortunately..

[bent98]

Would randy Davis be able to shed some light on the physics code

Edited by bent98, 07 February 2014 - 01:19 AM.

[mukuste]

Aw I'm so happy right now The reason I didn't post any screenshots lately is because I was optimizing and trying to get the framerate somewhere playable, the Scared Stiff table was languishing somewhere around 30 fps. I optimized all kinds of render calls but it just didn't seem to make much of a difference, fps-wise, so I already came up with the wildest theories what's wrong, or fearing that I'm just rendering too much stuff every frame. Only now did I finally think to run a CPU profiler on the whole thing, and guess what, I was actually CPU bound. Totally stupid reason too, it was just the texture lookup by name which does a brute-force search through all textures, comparing names along the way.

 

The upshot is that, after kicking that code out, I immediately jumped to >200 fps, producing the first truly playable DX9 version of a real table

[ClarkKent]

Wooooooooow!

[fuzzel]

Yeah baby

[GSGregg]

We're gonna need bigger smilies!

[JohnnyDoe]

This weekend is off to a tremendous start, thanks to Mukuste.

Thanks again for your invigorating updates.

[M4ttes]

Unbelieveable! Mukuste FTW!

 

And a very big THANK YOU!

[toxie]

Would randy Davis be able to shed some light on the physics code

 

I think the latest tweaks for VP9 were done by somebody else..

[gStAv]

Suuupeer Jaackpoot!

Edited by gStAv, 07 February 2014 - 12:16 PM.

[StevOz]

 

Would randy Davis be able to shed some light on the physics code

 

I think the latest tweaks for VP9 were done by somebody else..

 

 

Well yes and no, they did do that and Randy did try incorporate those into VP8, VP9 as it is now was and is based upon that VP7 revision, just pointing out the historical facts, thus the screwed up nudge physics that we have now and the total lack of a change log from VP7 to ultrapin.....remember ultrapin, guess most won't or don't!

Edited by StevOz, 07 February 2014 - 12:26 PM.

[unclewilly]

Really awesome stuff.
Ready and willing to test whenever you need.

Thanks for all your hard work

[Slydog43]

mukuste,

 

what kind of rig are you testing it on (what cpu, memory, os, graphic card)?

 

great work, please stay with it! we all love it

[The Loafer]

I think I need to stay out of this thread, getting too excited for this old man! Lol

[unclewilly]

right. Feel like we've been waiting for this for many years. The anticipation is killing me.

I think I need to stay out of this thread, getting too excited for this old man! Lol

[arngrim]

+100000

did you try to inject monster bash killer edition into the dx9 vp9 version? i wonder how many fps it runs, and compared to vp9 dx7 version

[The Loafer]

A comparison of MB in both vp9.2 and the current dev vp directx 9 version would be cool, but I suspect there's lots of bug hunting and optimizing before he is ready for those types of tests..

Edited by The Loafer, 07 February 2014 - 01:33 PM.