FluidPlugin Alpha out(CHECK OTHER THREAD)

This forum is currently in read-only mode.
0 favourites
From the Asset Store
Is a system for building scorecards and achievements online for use in games Using this system, you can create a scorebo
  • Wow... that is very nice! I'd say multicore is an essential feature, otherwise you simply won't get the performance out of it, and quad cores are becoming more common, so a 4x speedup would be great. The resolution is a bit blocky, but the blur covers it up really nicely.

    Also, why hijack a sprite mesh? If you're using set distort map actions in the event sheet editor, that's going to hammer the performance unnecessarily. Why not have your plugin draw the mesh itself?

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads
  • Wow... that is very nice! I'd say multicore is an essential feature, otherwise you simply won't get the performance out of it, and quad cores are becoming more common, so a 4x speedup would be great. The resolution is a bit blocky, but the blur covers it up really nicely.

    Also, why hijack a sprite mesh? If you're using set distort map actions in the event sheet editor, that's going to hammer the performance unnecessarily. Why not have your plugin draw the mesh itself?

    I got the multicore working, I juust need to add the code to autodetect the number of cores

    As far as the distort mesh, I meant you could just set a sprite to apply it to like a behavior and it would do it behind the scenes without actions in the event editor. As far as why I don't do it myself. The only way id know how is to copy paste all the sprite code,

    Which I guess could work, but it'd still be cool for plugs to be able to hijack meshes, not just for this plugin. it would work well with davos ribbon plugin, for example

  • The blur helps out quite a bit. Why even bother with meshes though? If you made it as a plug in and simply set the color of each pixel then draw it like an image, then by making the image take up the whole screen it would automatically interpolate, no looping through verticies required, and it would be much faster than using events. Then you'd also have one quad instead of a whole bunch of triangles, which would render faster.

    Admittedly I have no idea how to make plug-ins, though, so that might be a lot harder than it sounds. ^^

  • Graphics cards don't really have a 'set pixel' command - they do everything with vertices. You can set a pixel, but it is very slow!

  • Huh. I had no idea!

  • found a cleaner way to visualize, it runs faster, and looks better than the mesh method

    no pixelation at all, just pure silkiness.

    also in this demo, right mouse button erases smoke

    (save it into the same directory with the dll's from the other demos

    http://dl.dropbox.com/u/1013446/rockrocket.exe

    it's a canvas, and one soft circle sprite that pastes itself at the different spots in the grid after adjusting size, opacity, and color according to the thickness of the smoke

    I'll try to release the beta of the plugin this weekend, a little too much overtime at work at the moment. just want to add the auto cpu core detection, and some auto math functionality to make it so there's no math required to translate between layout and fluid coordinates.

    and for you retro folk:

    http://dl.dropbox.com/u/1013446/retrosmoke.exe

  • i have a question, how does the plug operate exactly, what would the actions, conditions, etc be?

    also i have some questions about how it runs, does it constantly use the same overhead no matter the amount of fluid, i assume it constantly processes a set space parsed into a grid or, does take more to do more?

    aaaand can it interact with solids/moving solids?

  • i have a question, how does the plug operate exactly, what would the actions, conditions, etc be?

    Right now the actions are "add ink"(smoke)(x index,y index, ink amount)

    And set velocity. (X index, y index, x component, y component)

    Set vorticity (the swirliness of the smoke, for instance the fire had a higher vorticity than the smoke)

    Set velocity advection. Advection is the preservation of a property as it moves through the fluid, so a higher velocity advection, the current wouldn't slow down as much as it moved through the fluid

    I will add the actions to set heat, pressure, amd ink advection

    I think its also possible to set the heat and pressure values at an index like you can with velocity

    Oh yeah, and anything you can set adveection for you can set diffusion for which is the tendency to dissapate

    Expressions are to get ink,velocity and later I think heat pressure for a given grid index

    Right now I'm doing the math to translate grid coords back and forth to screen coords in the cap, but it makes sense to have that done automatically, so ill build it into the plugin

    [quote:4b9vg3ll]also i have some questions about how it runs, does it constantly use the same overhead no matter the amount of fluid, i assume it constantly processes a set space parsed into a grid or, does take more to do more?

    think it does use more processing power with more ink, because in an empty space it only needs to calculate, the velocity and not any ink advection, but I don't think more and more ink slows it down even more, I think any ink present in any given grid coord adds the cpu time, but after there's some ink there, more ink doesn't slow it down more, of course, it could be the way I was applying it visually, ill let you know more as I figure it out

    [quote:4b9vg3ll]aaaand can it interact with solids/moving solids?

    I sure hope so. Its not built in to the library, but I think I maybe able to use the wall hitting functions to be able to add obstacles, even if they can't be at an angle for now...ill let you know if it works

    EDIT: oh yeah, almost forgot, I want to add a for each loop for eachloop index, with parameters for greater than values you can set for ink, velocity, etc

    Almost any implentation I can think of involves a nested loop for 0 thru gridsize x, for 0 thru gridsize y, and sometimes if ink at loopindex("x"),loopindex("y") is greater than whatever do this

    So ill have expressions for ink at loopindex, velocity, etc,and the conditional for each loopindex thing will make it very simple

    Also before I stated it has the action to set ink and velocity at index, I think it should be for screen coordinates or indexes

    And finally I forgot to say, an action to set the size of the grid

    All the grids in these demos have been 50x50 visually, though all except for this last post with the smooth and retro versions have been calculated at 100x100 size, just for speed testing purposes

  • Ok. The retrosmoke is amazing. And it almost doesn't lag.

  • Ok. The retrosmoke is amazing. And it almost doesn't lag.

    Runs 60fps constantly here :/

    I get slowdown on the particle one with the chunky white dots flying around. I got that dropped to 20fps after holding the button for 20-30 seconds.

    I thought you had a pretty up to date PC davio?

    ~Sol

  • 1.8 ghz dual core, 2GB ram, HD 4670 512MB. Not top of the line, but I wouldn't call it out of date. . And just the fact that one of the demos lags on your pc speaks worlds about the plugin's performance. I've run fluid sims before and they mostly all ran better than this.(no offense lucid!) The low performance must be because of the construct implementation or just the general unfinished/unoptimized state of lucid's awesome plugin. I hope that future versions will run at more acceptable speeds.

    This is the kind of performance we need lucid.

    http://www.escapemotions.com/experiment ... index.html

  • 1.8 ghz dual core, 2GB ram, HD 4670 512MB. Not top of the line, but I wouldn't call it out of date. . And just the fact that one of the demos lags on your pc speaks worlds about the plugin's performance. I've run fluid sims before and they mostly all ran better than this.(no offense lucid!) The low performance must be because of the construct implementation or just the general unfinished/unoptimized state of lucid's awesome plugin. I hope that future versions will run at more acceptable speeds.

    This is the kind of performance we need lucid.

    http://www.escapemotions.com/experiment ... index.html

    The slowdown in the particle deal was cuz of the implementation in construct

    It was just spawning particle objects each tick

    Aside from that while multicore isn't enabled for these, it probably won't be superfast like the impressive nvidia smokebox demo, running on hundreds of stream processors instead of 2 to 4 cores( copuldnt view link on phone)

  • Ok wait, I take that back, it should be possible to make it much faster

    I didn't think about it, but it was still doing crazy amounts of events to spawn those sprites, so upon davio's doubtiness, I tried running the simulation without sprites

    And it ran much more quickly, then I tried it again with 5000 sprites, but no events to do anything to them, but bullet behavior to ensure they were still moving on screen,

    Even on my craptop is was still going at 89 fps, so

    Ill have to think about how tbhis can work, but it may be possible to run this very quickly

    Unfortunately, it'll involve some sacrifice, it'll require more gpu power creating a sprite for ewery spot on the grid, but much less overhead on the construct event system.

    But it could have the flexibility to do something like the particle method, or the retro method. I'm guessing no one needs the ugly mesh method

    I need to think about this maybe even learn how canvas plug works and take some of that code

    Either way. I have to think about this, if anyone has any ideas let me know

  • making each fluid effected particle a smooth gradient circle applying an effect like colourise over it might look cool, mix of fluid and quaz blobs , and with the plugin tulamide was working on for blobs and palletizing this could work really nice

  • anyone who wants to help please run this

    download(720k)

    this is a 50x50 grid of fluid, and 2500 moving sprites taking advantage of multicore processors

    you won't see anything on the screen happening but just move the rocket around randomly

    it's adding ink nonstop invisibly, and all the testing is going on in the background

    I'll try to make another larger gridsize benchmark in a little while, but this should start to give use a general idea of how it could run

    after you've given a second for some ink to get out, please left click, and then paste into a reply to give me your benchmark data

    please paste, and don't just give your fps, because it will help me verify it's recognizing all cores

    if you want to add your gfx card info that'll be useful mainly only if it's not running over 100 fps

    thanks anyone who helps,

    here's my info:

    fps:302

    threads:4

    cores:4

    Advanced Micro Devices

    3415mhz

Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)