Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

Dark Physics & Dark A.I. & Dark Dynamix / Fluids are too slow for there own good?

Author
Message
dark coder
16
Years of Service
User Offline
Joined: 6th Oct 2002
Location: Japan
Posted: 17th Sep 2006 10:59
Hey all,

I got myself a bfg ppu the other day so that I could essentially enter the hardware compo, and I had hoped to use some fluids in my game idea to help spice it up and make it look better, however when I ran the very basic fluids demo(fluid blob) I get around 40fps, and when I use asyncronus updating I get around 48fps, and the other fluid demo with the barrels(slime) I get around 38-42 fps, now I dont think its my hardware that is the issue, as I have 2gigs ram, 2x 7800gtx, x2 4400+, those results are without sli, as I assume most people would have a single gpu setup and with sli I get prettymuch identical results.

Also, my pc was recently reformatted like 2-3days ago, and from a fresh reboot, without any other processor intensive apps running, I have the latest windows updates, latest drivers for my gpu/ppu, and the app is running in the default 640x480? window.

And I have a little theory why it's slow, could it be due to the ppu having to update the gpu mesh data? cause on something as potentially highpoly as a fluid mesh would be a slight drain when updating it in realtime, cause at the current state they arent really useable due to the slowdown, So I was wondering if its just my pc, or the implementation into dp wasnt as optimized as in other engines, and/or if there were any plans on speeding it up, cause for now it looks like I will have to dump tonnes of colliding particles to make up for it :p.

Hallowed are the ori.
Mike Johnson
TGC Developer
16
Years of Service
User Offline
Joined: 13th Sep 2002
Location: United Kingdom
Posted: 17th Sep 2006 13:28
You can improve the frame rate significantly by experimenting with some of the properties. Here's a few things you can try:

* decrease the particle buffer cap as this will have a major bearing on things

* increase the level of damping as this will reduce the velocity of particles faster and help to decrease the amount of calculations

* look at the viscosity property, modifying this can have an impact on the frame rate

* perhaps modify phy set timing, the default number of maximum iterations is 8, you can always reduce this to a lower value e.g. phy set timing 1.0 / 60.0, 60 / 20, 0. This basically sticks to the recommended 60 hz rate for PhysX, the second part 60 / 20 says the game is playable down to 20 fps and the final parameter sets fixed step timing
Xarshi
13
Years of Service
User Offline
Joined: 25th Dec 2005
Location: Ohio
Posted: 17th Sep 2006 19:01
wow...I tend to get 30 fps or less for anything,even a single cube

Working on DBIrr. Done so far : objets,lights,cameras,billboarding. To come: newton game dynamics support,Animation blending with cal3d.
dark coder
16
Years of Service
User Offline
Joined: 6th Oct 2002
Location: Japan
Posted: 28th Sep 2006 10:08
Hey Mike,

I tried all the things you suggested, and managed to get the fps to around 50fps(max) and this is just with a 500-2500 poly fluid blob falling onto a plain, I tried editing the physx timing, but most values I tried made the fluids all seperate but the fps never really increaced when I tried those.

Setting the particle cap to anything under 4000, seemed to cause a windows error, changing the damping made it look different but the fps was pretty much the same, so as a small request, could you produce a demo that has active fluids and the fps would run at over 100fps on my pc?, cause everything I have tried doesn't even get close, and 100fps for something as basic as the scenes I have been trying should get alot more but 100fps is a good starting point.

Also the container demo, (other than the fluids seem to pause at one time) if you move the camera into the container area I get a internal driver error.

Hallowed are the ori.
Mike Johnson
TGC Developer
16
Years of Service
User Offline
Joined: 13th Sep 2002
Location: United Kingdom
Posted: 28th Sep 2006 12:19
With the current implementation it's unlikely you will see such high frame rates. The best I've probably managed is around the 60 mark. Getting much higher than that is unrealistic right now. I've yet to see any demo from Ageia that runs particularly fast either so I'm not certain we can get better performance.

This may all change very soon though as Ageia are constantly working on updates and their SDK is improving all the time which in turn will bring improvements to Dark Physics.
Chenak
16
Years of Service
User Offline
Joined: 13th Sep 2002
Location: United Kingdom
Posted: 1st Oct 2006 14:15
I was looking forward to using fluids until i see the fps drops to below 15. There must be a way to reduce to polycount of these things, setting the fluid particle cap to below 4000 will be a good start since it says in the manual it should be set to around 2000 and it effects performance.

So fix this bug please.
dark coder
16
Years of Service
User Offline
Joined: 6th Oct 2002
Location: Japan
Posted: 1st Oct 2006 16:05
Hey Chenak, if you run the demos add the line 'Text 0,0,Str$(Statistic(1))' , You'll see the polycounts clearly arent the cause of the slowdown, they maybe linked to it cause the card must update the gpu`s mesh data however.

Hallowed are the ori.
Cash Curtis II
14
Years of Service
User Offline
Joined: 8th Apr 2005
Location: Corpus Christi Texas
Posted: 3rd Oct 2006 00:03
Quote: "they maybe linked to it cause the card must update the gpu`s mesh data however."

dark coder, isn't that what is happening with cloth? I mean, the cloth mesh data must get updated every Phy Update as well, but it isn't in itself a source of major slowdowns.


Come see the WIP!
Chenak
16
Years of Service
User Offline
Joined: 13th Sep 2002
Location: United Kingdom
Posted: 4th Oct 2006 00:08
It definately should not be that slow, if its a darkbasic or a physx problem I don't know, but I expect it to be at least 60fps on my computer with nothing else running apart from the fluid and a collision object.
General Reed
13
Years of Service
User Offline
Joined: 24th Feb 2006
Location:
Posted: 15th Oct 2006 16:02
Fluids are only worth it for small effects, like a drip from a tap, realisticly flowing down the sink etc.

AMD Athlon 64 3200+, 1GB ram, Geforce 6600 GTX, 80GB HDD
Vist www.scratchyrice-dev.co.uk
dark coder
16
Years of Service
User Offline
Joined: 6th Oct 2002
Location: Japan
Posted: 15th Oct 2006 17:25
Or in there current state they are usefull for simulating lag

Hallowed are the ori.
Raven
14
Years of Service
User Offline
Joined: 23rd Mar 2005
Location: Hertfordshire, England
Posted: 15th Oct 2006 18:46
I'd suggest finding alternative uses, if you want bouyancy then add it seperately and use standard particles for the fluids. It might not have the metaball globbing effect but using the GPU you can change that quite easily (the DirectX SDK has an example shader for doing just that with particles at high-speed on even low-end cards like GF6200 or X1300)

Use the fluids themselves for things like interactive low-laying fog and blood splatter. If you notice that's all it's used for in Bet on Soldier and Cellfactor as well. No doubt something to do with the engine given the pure performance upgrade you get when you have a PPU for objects it can overall handle. Probably something to do with their metaball code... it's difficult to perform that quick without direct gpu access for the mesh positions.

As I mentioned the DXSDK has a good example, as it fakes it by using sprites that are blended using the pixel shader and a wave pattern.

Intel Pentium-D 2.8GHz, 512MB DDR2 433, Ati Radeon X1600 Pro 256MB PCI-E, Windows Vista RC1 / XP Professional SP2
bosskeith
13
Years of Service
User Offline
Joined: 5th Dec 2005
Location:
Posted: 16th Oct 2006 23:57
fog would even be a poor use of the liquid function because that effect would be better suited for particles too. because you caqn set the particles to both effect objects and be affected by you.

Login to post a reply

Server time is: 2019-07-23 22:58:09
Your offset time is: 2019-07-23 22:58:09