Hi there. I saw that you implemented the visible property for particles. Thanks! However, I'd like to add some custom stuff to the Particle class and tried to sublcass it. That didn't work, because Particle was declared as public final class. Is there a reason, that it's public final? That's kinda limiting in my opinion.
Best - Roman On Feb 2, 10:38 am, katopz <[email protected]> wrote: > Hi Roman > > i'm glad someone playing with it ;D , let me separate things > > The scene.bitmap approach is quite limiting > > yup, alot more in todo list, this bitmap feature just added yesterday ;) > > because it doesn't allow> for different blend-modes or filters per > Particle-System. > > // each particle post render, internal > for filters : you have to do it manually by *applyFilter *to bitmapdata > for blendMode : you have to do it manually by *draw *bitmapdata again with > blendmode > > todo : i'll add this as properties and auto apply while draw soon, or you > can do it yourself in case you got my idea what i said ;) > > // each particle pre render, external > they all use same bitmapdata, so you can try apply all effect to source > bitmapdata once from external and expect magic happen > > todo for this is cached scale and blur for dof > > for flters/blendmode all particles : you can do it by addChild scene.bitmap > to some sprite that already apply blendmode/filters > > > container = new Sprite(); > > container.filters = [new BlurFilter(4,4)]; > > container.blendMode = BlendMode.ADD; > > addChild(container); > > container.addChild(scene.bitmap); > > should work > > Couldn't this have been > > > solved by setting the "layer" property on the Particles object and > > then render all particles belonging to that Particles Object on its > > layer? > > yes, normally it would be, something like that > but it's a little bit fancy while render loop and sorting > i've to collect all particles(s) for sorting and draw them by z depth (layer > already mix at this state) > > On the other hand: having a layer per Particle seems to be > > > overkill though. > > it's just for referrer for render target as i said above, it's not good idea > to add filter per layer per particle in case you have hundred particle to > render ;) > > Also: It would be really useful to have a "visible" property on > > > particles. > > yup, already in my todo list, plus rect clipping > > Particle.as, here's a patch: > > >http://bummzack.ch/misc/Particle-Visible.patch > > thx! > > more todo : just talk with muzer jiglib team that i'll add physic to > particles, and this should be fun after thing done! ;D > > plz alert what you need and do help me testing for best both speed/usability > away3d team love to hear what you guy think and let push flash to limit! > > anyone want to help me kill todo for this is welcome! it's totally fun, > trust me! ;) > > cheers! > > On 2 February 2010 14:57, banal <[email protected]> wrote: > > > > > Hi katopz > > > I had a more close look at the particle implementation and a few > > questions popped up: > > The scene.bitmap approach is quite limiting, because it doesn't allow > > for different blend-modes or filters per Particle-System. > > Is there a reason that particles use another construct like > > "scene.bitmap" instead of "layer" or "canvas"? Couldn't this have been > > solved by setting the "layer" property on the Particles object and > > then render all particles belonging to that Particles Object on its > > layer? On the other hand: having a layer per Particle seems to be > > overkill though. > > Or at least a Bitmap per Particle-System (Particles.as) > > > Also: It would be really useful to have a "visible" property on > > particles. This can be implemented with only a few lines in > > Particle.as, here's a patch: > >http://bummzack.ch/misc/Particle-Visible.patch > > Maybe Renderer and Particle could be updated as well, so that they > > check the visible flag first before performing any action with the > > Particle. Just to save CPU time. > > > Thanks for your efforts > > Best regards - Roman > > > On Feb 1, 5:56 pm, banal <[email protected]> wrote: > > > Hi > > > > Thanks a lot for that hint. I have to check if I can make it work > > > without z-sorting/occlusion of particles. > > > The scene.bitmap approach doesn't have these issues. > > > > Maybe it's still worth it to investigate the problem when using the > > > "old-fashioned" particles. > > > > Cheers > > > > On Feb 1, 5:20 pm, katopz <[email protected]> wrote: > > > > > Hey guy > > > > > i just update particles today in branches, also add some bitmap > > renderer for > > > > particles > > > > here's some test for old draw style vs new bitmap render > > > > >http://away3d.googlecode.com/svn/branches/lite/bin/ExParticles.swf > > > > > i saw your code didn't use new approach like this > > > > >http://away3d.googlecode.com/svn/branches/lite/src/ExParticles.as > > > > > > scene.bitmap = new Bitmap(new BitmapData(stage.stageWidth, > > stage.stageHeight, true, 0x00000000)); > > > > > > addChild(scene.bitmap); > > > > > > which mean you render with normal graphics.beginBitmapFill and > > drawRect > > > > > in the mean time you can try switch to scene.bitmap in case you didn't > > need > > > > sorting/scale for particle again other object3d > > > > you will gain extra 2x fps for this, and let see your issue solve or > > not > > > > > i'll take a look this issue again...ASAP, thanks for report > > > > > cheers > > > > > On 1 February 2010 22:37, banal <[email protected]> wrote: > > > > > > Hello List > > > > > > This is my first post, and I'd like to thank the developers for all > > > > > their efforts the put into this marvelous 3D-Engine. > > > > > > I'm currently using the latest SVN (rev. 2163) of Away3DLite for a > > > > > Game. It all runs well, I even got some spare cycles I'd like to use > > > > > for a particle system. > > > > > > Sadly, the particle system creates artifacts near the emitting point > > > > > of the particles. I put together an example class, that demonstrates > > > > > the phenomenon. > > > > > Here's a screenshot that shows the problem: > > > > >http://bummzack.ch/misc/artefacts.png > > > > > > Here's the compiled test-case: > > > > >http://bummzack.ch/misc/TestCase.swf > > > > > > And here's the full code listing: > > > > >http://pastie.org/804256 > > > > > > I don't know if this even can be fixed by the Away3D devs.. I suppose > > > > > it's rather an issue with BitmapData.copyPixels() ? > > > > > > What do you guys think? > > > > > -- > > > > katopzhttp://www.sleepydesign.com > > -- > katopzhttp://www.sleepydesign.com
