First a big sorry for reviving this old thread. For personal reasons I quit devoloping the app soon after writing my last post. I've retaken it some time ago and reviewing this thread... I left two responses from Li and David unanswered. Please, accept my deepest excuses for such unacceptable delay.
I know it's a "little bit late" but at least I'd like to write a short response: David: Definitely a big texture size is a big issue working with pixel bender. The planets move slowly but there must be fast updates due to camera movements so for the time being I'll have to stick to the classic shaders. Li: I do have taken a look at Away3d lite but unfortunately it doesn't have Phong shaders. It's really a pity because Away3d lite with Phong shaders would fit exactly with my project. For light directions I'm using a normalized vector now, so no more scale issues... Well, there have been changes to DirectionalLight3D class but unfortunately the issues I had still remain. I'll come back to this but for now... I give up :( BTW, www.betaeridani.com no longer exits. The final domain name for the site is www.online-simulator.com Thank you for your time guys and again apologies for the huge delay. Jon 2009/10/25 David Lenaerts <[email protected]> > Hi Jon, > > The artefact looks to me like the normal map was generated from a lower-rez > sphere. I love how the shading looks apart from that tho :) > But yes, the PB shaders' performance are heavily dependent on texture size > (in fact, that's the only performance dependency they have). This is due to > the fact that Pixel Bender is used, it performs precise lighting > calculations for every pixel. And 4096x2048 is massive for a platform > without hardware acceleration! But, if your planets are moving in real-time, > it's probably not necessary to have the shader computed on every frame. > There's no autoUpdate property on shaders, but you -could- easily hack them > in, and update your shader manually every 15 minutes or so using > material.updateMaterial(mesh, view); > If you don't want to be concerned about radius and fallOff, you can just > set fallOff to Number.POSITIVE_INFINITY; > Another option is to use the Dot3BitmapMaterial, which also uses normal > maps but uses directional lights instead of a point light. Calculations for > directionals are always faster, so it might be worth it :) > > Hope that helps, > David > > On Sun, Oct 25, 2009 at 5:39 AM, Li <[email protected]> wrote: > >> That artifact is actually pretty neat! No idea what might be causing it >> though... >> >> I'm afraid that I really can´t help you much more as you reach this point. >> All I know is that, with the proper work and research, Away3D is perfectly >> capable of producing what you want to create, just get the proper answers >> from the proper people in this list. >> >> Suggestion A) Have you considered using Away3dLite for this? If you >> haven't, I'd recommend you to check it out, it would allow you much higher >> performances. Be sure to be aware of the feature limitations in it before >> starting though, it does perform much faster than Away3D, but has less >> features. >> >> Suggestion B) I think your app should have a scaling filter parameter. In >> the mathematical model of the planets you have a certain scaling. The >> numbers used in rendering should be independent from this BUT related to the >> numbers of the mathematical model through a given, arbitrary factor. I dont >> think that this should have implications on the actual rendering, I just >> think that it would make it esthetically tidier and make you feel you have >> control over these scales on your implementation. >> > > > > -- > http://www.derschmale.com >
