Hi, I've broke down one large texture into smaller tiles as when I was working with a single texture ( say 1024x1024 ) and updating that every frame the framerate was dropping more. Basically the large texture i am modifying doesn't all change every frame so pushing all to the GPU wasn't necessary. So depending on which tile updates i just push those tiles. This kept the framerate really smooth.
I didn't benchmark the updateTexture() properly, just visually. When i update just the texture, say 10 tiles at a time the framerate is really usable but as soon as i push the normal map as well ( extra 10 tiles, using the method above ) you can see there is a lot of latency in comparison. Perhaps there should be no difference but as i was hacking the normal update in myself i assumed this was the problem. Perhaps with how Away3D handles the normal map update using this method. And just looking into AGAL at the moment but mainly through pixelbender3d/minimole ( https://github.com/lidev/minimole-core ). I've found this good for exploring pixelbender3d within a 3d engine. As I can't see if pixelbender3d was used for programming Away3D's Default Shading Methods? Also do you know if it's possible to update a texture on the GPU from within a fragment shader? ( So rendering to a texture). If this is a no, i'm assuming you'd have to render to the screen then capture the area in Actionscript and pass back to the GPU? I'd use this as If i was calculating a normal map on the GPU I wouldn't want to update a normal map every frame. Only when the bump/height map changes for that tile. If that makes sense? Cheers, Jamie On Aug 24, 9:19 am, richardolsson <[email protected]> wrote: > Hi, > > First of all, if you are using textures that are just 64x64, wouldn't > it make sense for you to merge textures into a texture atlas, to > decrease the number of textures (and thus the number of uploads that > need to happen to the GPU)? > > How are you doing the comparison that concludes that your > updateTexture() is significantly slower than the normal one? > > Finally, you can definitely design your own shader and plug it into > Away3D (as a "shading method" that you can apply to your materials) > but it requires that you know AGAL. Have a look at how the existing > shading methods are built for a reference on how to do this. > > Cheers > /R > > On Aug 23, 3:17 pm, jamie655321 <[email protected]> wrote: > > > > > > > > > HI, > > > I had a couple questions regarding normal maps/custom shaders. > > > I've been trying to figure out the best way to update a > > BitmapMaterial's normalMap ( along with the texture ) per frame. The > > current way I have been achieving this ( probably not correct ) is by > > extending the BitmapMaterial class and overriding updateTexture(): > > > override public function updateTexture():void > > { > > super.updateTexture(); > > var normal:BitmapData = _screenPass.normalMap; > > > _screenPass.normalMethod.normalMap = null; > > _screenPass.normalMethod.normalMap = normal; > > > } > > > This invalidates the normalMap bitmapData ok and updates, however the > > update is significantly slower in comparison to the existing > > BitmapMaterial updateTexture() method when just updating the texture. > > Is there any reason why updating normal maps would be slower, perhaps > > because the Shader Program needs to be uploaded again when modifying > > normal maps? > > > Second question, is as i'm calculating the normal map data from a bump > > map on the CPU side of things which is really slow anyway, ideally i'd > > like to be able to create a custom shader to receive a bump/height map > > ( which is initially updated on the CPU ) as a parameter and > > recalculate the normal map on the GPU side. Any ideas on how/if this > > is possible to integrate with the current Away3d framework so that > > you'd get a good framerate, bearing in mind i'm working on 64x64 > > textured tiles with may be 10-20 max being updated/calculated per > > frame? > > > Thanks, > > > Jamie
