Hey Roman i don't think about extending it, so it declare as final i'll get rid of it in case you need it then just don't forget to show your stuff after thing done, i love to see ;)
and here's some more i found about Artefacts http://blog.nobien.net/2010/02/09/using-bitmapdata-to-improve-performance-and-one-small-annoyance/ but i can't find easy way to apply this fix yet ;p cheers On 20 February 2010 20:45, banal <[email protected]> wrote: > 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 > -- katopz http://www.sleepydesign.com
