On 21-Mar-04, at 2:05 PM, Chris Dillman wrote:
1) Crash: You cannot extract a picture from an invisible or
off-screen RB3DSpace or one that has a width/height of zero. I found
a workaround for this in that a control of size -1, -1 allows you to
extract the picture, os I guess this is not a big deal. RS never
repsonded to my previous report on the subject so presumably they
feel the same way.
Although I agree this crash should be fixed, there's really no point in
grabbing a 0x0 texture (is there?)
2) Performance: Extracting a picture from RB3Dspace is too slow to do
in real time (by realtime I mean at 30fps on a modern machine).
Quesa would need some sort of pbuffer API extension for this to improve
(which would be a reasonable request). At the same time it may be fast
enough if you had direct access to Quesa's texture cache through RB3D.
I'm working on some declares that may allow for this eventually, but it
will still be a roundabout way to go about it.
3) Performance: Building a texture from a picture is too slow to do
in real time for a decent sized texture (512 by 512).
Yes. Quesa does a lot of extra work on textures (e.g. keeps a local
copy in case the context needs to be rebuilt). Make sure you always use
AddShapePictureWithMask in RB3D as much as possible (even if the mask
is solid) otherwise RB3D will try to create a mask from white pixels,
which takes time, even if there are no white pixels.
4) Performance: Using large numbers of object3Ds (more than a few
dozen) causes great performance degradation. This does not seem to be
connected to the number of polygons being rendered and so must be due
to a coding bottleneck in Quesa or RB3D rather than the graphics
card.
I'd say it's more Quesa than RB3D since RB3D+QD3D is pretty quick with
similar object counts. Some preliminary profiling suggests Quesa spends
a whole lot of time doing hash lookups...
One thing Quesa could possibly do to improve pure render speed is
combine like-objects into one big vertex array ("alike" as in using the
same texture, or untextured). As it stands, it appears Quesa draws
objects as they come, so drawing 100 cubes is way more work than
drawing a single trimesh that contains the exact same geometry. Hash
lookups aside, drawing a bunch of small vertex arrays can often be
slower than immediate mode, and could result in unnecessary texture
binds to boot.
There are also vendor-specific GL vertex array extensions but I won't
get into those - The fact remains that it looks like Quesa needs to get
the geometry to the _renderer_ faster, not necessarily to the
_hardware_ faster.
5. Apple highly recommends that GL engines do not use the glFinish();
command.
I thought this was settled on the Quesa NUG (Nanasaur may be calling
Q3View_Sync or something). At any rate, I've seen no change in
performance through RB3D with this change - I don't think Quesa calls
glFinish under normal circumstances, only when an app or renderer
explicitly flushes the context.
On a similar note, one feature I plan to add to the Quesa Wrappers is
access to a view's clear flags. Turning off colour buffer clearing can
help greatly for scenes that cover the entire drawing surface (e.g with
a skybox or background image).
6. A Direct 3D renderer.
Would be nice.
7. Some sort of bones support.
Even just linearly interpolating a mesh by controls.
I agree it would be nice to have something built-in, but this stuff
tends to work best when it's application specific (especially bones).
8. Low level access to lines, points, vertexes etc so that objects and
meshes can easily be built on the fly...
We discussed the pros and cons of this previously (it's complicated due
to how 3DMF's, and hence Object3D's, are structured). Not the answer
you're looking for, but this is possible (and quite easy) in RB5.5 with
the Quesa Wrappers.
9. A way to iterate through the above lists of objects.
Again, I know this isn't the answer you're looking for, but this is
possible (and quite easy) in RB5.5 with the Quesa Wrappers.
10. a Command a long the line of optimize object...
That might take a list of points/tris etc and rearrange them short
them ect
into a a mesh or into a more ordered set of data that can be submitted
to the 3D card faster.
That's really a pre-processing step you need to do yourself, preferably
at the modeling stage. Geometry optimized for one app won't necessarily
be suitable for another app.
11. Quesa should get if it does not yet have some sort of internal
caching system for objects and for objects made of of immediate mode
calls.
Again, I think this was agreed upon on the Quesa NUG (whether it gets
done or not is another question).
Frank.
- - -
Unsubscribe or switch delivery mode:
<http://support.realsoftware.com/listmanager/>
Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>
|