Passing calculations to GPU is not just an option, but the best way to optimise. But the question is in technical implementation. I dont know Molehill so good yet to talk about technical implementation of vertex coordinates extraction.
Caching is always good, but I dont imagine what could be cached, as particles are in motion and coordinates are changed in each frame. But, basically we must keep the initial coordinates in a separate object, and calculate new position in each frame, and the initial object will remain in a kind of cache. But this initial object changes vertexes positions if we have some more complicated motion inside particles field. About Flint, we need some good architecture to easily extend or reuse modules. From this point of view, Flint is good. But I cant say that it is the only one solution, because all that matters is extendability and reusability. So for now, the main question, is how we can extract raw coordinates from the GPU calculated objects? On May 5, 6:04 pm, Michael Iv <[email protected]> wrote: > Passing some calculations to the GPU is obviously an option. But I am not > working on particle engine from scratch but extending Flint . So it is not > so easy to implement it. From the other hand I though of adding buffers to > hold already created particles like a poll and Reuse them. In such a > case I can save A lot of > Cycles needed to instantiate the particles. > > Sent from my iPhone > > On May 5, 2011, at 5:37 PM, Arkadianen <[email protected]> wrote: > > > > > Very interesting topic for me. I wrote this > > articlehttp://alexgblog.com/?p=722 > > and I achieved decent framerate with 800 particles. > > > Can we extract 3D vertex xyz position in Molehill? And probably, a > > Sprite3D can be rendered by GPU. Maybe we can even increase the speed > > of calculations by using PixelBender 3D. Maybe... > > > On May 4, 3:31 pm, Michael Iv <[email protected]> wrote: > >> Thanks for this info. Yeah , I thing this is related to the optimization . > >> Also I tested Flint with Flare & A3D Sprites and the performance is shitty > >> there as well. > > >> Sent from my iPhone > > >> On May 4, 2011, at 3:24 PM, ringodotnl <[email protected]> wrote: > > >>> Aloha Michael, > > >>> Having lots objects needs to be optimized, the team is looking into > >>> that. > >>> As far as I know, the particles aren't picked-up yet but it's high on > >>> my wish list as well :) > > >>> I don't know if anyone is working on a optimized (gpu) particle system > >>> (Simo?:)) but it's sure something I want to look into when time > >>> allows :) > > >>> Cheers, > >>> Ringo. > > >>> On May 4, 10:58 am, Michael Iv <[email protected]> wrote: > >>>> Thank for this info man. That is approximately the number of sprites I > >>>> can run too. Although after 400 the FpS is as low as 4-5. I guess for > >>>> the particle system there is a need to develop a separate molehill > >>>> engine > > >>>> Sent from my iPhone > > >>>> On May 4, 2011, at 11:47 AM, Jahiro <[email protected]> wrote: > > >>>>> I've had major performance issues with Sprite3Ds and bitmap materials. > >>>>> I ended up having to write a culling class that uses a quad tree to > >>>>> track down which Sprite3Ds are closest to the camera - I keep the > >>>>> close ones and cull the rest. Would love to see sonme optimizations > >>>>> around Sprite3Ds. > > >>>>> Michael, I found that running a release build gave me an increase in > >>>>> fps, but still I can't run my app at all with more than 500 sprites at > >>>>> any one time, even with a release build. > > >>>>> On May 4, 7:33 am, Michael Iv <[email protected]> wrote: > >>>>>> Btw , anybody knows if the 2d molehill engine M2d supports depth ? > >>>>>> Would be interesting to test it in correlation with Flint. > > >>>>>> Sent from my iPhone > > >>>>>> On May 4, 2011, at 12:20 AM, makc <[email protected]> wrote: > > >>>>>>> On 3 ôÒÁ, 23:40, Peter Kapelyan <[email protected]> wrote: > >>>>>>>> Did you try this demo, says like 4096 items > > >>>>>>> It also says December 24th, 2008
