[Papervision3D] Optimizing performance: anything else I can do?
apinstein at mac.com
Fri May 8 22:33:25 PDT 2009
Yes, the quality suffers significantly.
The images are high-resolution, and often have crisp details that
cause visible motion artifacts.
Two common issues:
1) Water, which has highly contrasted pixels next to each other. When
in motion, it looks like the screen is twinkling.
2) Straight lines from windows, doors, etc. These flicker quite
noticeably as well as exhibit distracting jaggies in low-quality mode.
On May 9, 2009, at 1:28 AM, Gil Birman wrote:
> Cool dashboard and thanks for the tips :) Why is it exactly that you
> can't use low quality? Does the quality of the images suffer too much,
> or is it the interface?
> On Fri, May 8, 2009 at 11:11 PM, Alan Pinstein <apinstein at mac.com>
>> First of all, thanks for Papervision, it is great. Good docs, good
>> community, good product.
>> We have built a virtual tour viewer based on Papervision and of
>> course I'm
>> trying to squeeze out as much performance as possible. Here's the
>> [there's a bunch of panos starting with the 3d image]
>> Of course performance is pretty good at reasonable screen sizes,
>> but at full
>> screen especially on large monitors things drop to 10-12 fps or
>> worse on
>> modern hardware.
>> I have read as much as I possibly can (20+ hours) about Flash
>> Papervision performance, etc. I have spent another 20 or so hours
>> various techniques. Here's a summary of what we've done:
>> 1. No interactive viewports.
>> 2. Flash quality medium (can't go lower; too much aliasing)
>> 3. Minimized polygons (I even wrote a custom cylinder subclass with
>> specialized tessellation to remove polygons).
>> 4. Using even less polygons, but using precise=true, precision=8
>> much required to get good subjective quality). This was faster than
>> precise=false with enough polygons to improve quality to acceptable
>> 5. We have only 1 camera pointing at 1 object. There are typically
>> about 500
>> polys in full-screen mode.
>> 6. Mipmap-friendly dimensions (of course this only matters at smaller
>> viewport sizes since we don't ever see our textures from far away)
>> Since our product is a "High-Definition" tour player we
>> unfortunately can't
>> compromise on the things that matter most (smoothing, stage quality,
>> polygons/distortion correction). I am just trying to make sure I've
>> everything I can.
>> I have even bought the Flash profiler and compiled against the pv3d
>> to profile the app.
>> The thing that surprised me the most about this is that about 80%
>> of cpu
>> time is in [render]. I cannot find an acceptable explanation of how
>> internals works that would cause this to be so slow. I routinely
>> full-screen movie trailers in flash and they are able to keep high
>> framerates, so I wonder why if PV3D rendering takes only 20% CPU
>> why can't
>> [render] keep up with 80% headroom?
>> The only suggestion that's been made to me is to reduce the main
>> size (right now a very big one, using BitmapDataUnlimited it's
>> max). I have played with setting different materials with
>> geometry.faces[i].material and have had some success.
>> Here is a link to one where I have sliced the texture into 3
>> instead of 1 giant BitmapMaterial:
>> It seems little faster, but it's hard to tell for sure. In any case
>> I still
>> have outstanding problems with the seams which I'd need to fix to
>> be able to
>> use this. [btw anyone know how to fix that problem?]
>> The problem is, I don't understand *why* this is faster. The input
>> data is exactly the same, so why should this affect speed? Without
>> understanding why this matters, I can't decide the most appropriate
>> way to
>> slice things up. Should I use 2 slices? 16 slices? 100? Do the pixel
>> dimensions of the slices matter? Should I use tiling to arrange the
>> textures, or custom UV mapping? How will that affect performance?
>> I have a decent background in optimization. I understand lock
>> competing resources, profilers, general code optimizations, etc.
>> I've used
>> profilers on about 5 different platforms for over 10 years. I just
>> have enough visibility into how Flash and/or Papervision work to make
>> further improvements or understand why I cannot get further
>> I am definitely willing to put in more time to making improvements
>> in my
>> code and even the PV3D source if needed, but at this point I am just
>> guessing and need some direction!
>> Thanks in advance.
>> Papervision3D mailing list
>> Papervision3D at osflash.org
> Papervision3D mailing list
> Papervision3D at osflash.org
More information about the Papervision3D