Ahh, I get it. You're talking caching of draw triangles. I mean,
triangles which already exist wouldn't be very poolable.
Now, actually, the triangle caching thing was clear to me. The ITM3
game was impressive. But it's a one shot performance optimization. It
only works with a static camera. That being said, yes memory stability
is another form, and I should've named it pooling. Was just to fast it
typing.
Regards,
Ralph.
On Mar 9, 2009, at 9:09 PM, Rob Bateman wrote:
Hey Ralph
Considering that your triangle caching system only works when
objects haven't moved in relationship to the viewport, this benefit
would only be apparent during those situations, right ?
actually it runs deeper than that. thanx to object pooling, the
number of data primitives is kept under close control and never
exceeds the maximum number used onscreen at any one time. The
current game we have running that uses Away3d, ITM3, uses this
technique extensivly. Where previously, memory would rise by up to
20 megs per room in the game (each room can have anywhere from 5000
to 50000 polys), this becomes unworkable when you have to swap up to
15 different rooms per level, and at the same time allow the game to
be played for up to an hour! Object pooling solves a lot of these
kind of problems.
The clipping system we have uses triangle caching, and overall no
difference is noticeable
i expect you would see a difference if you created and destroyed a
lot if different objects onscreen over a period of time! And you are
presumably talking about caching in the sense of pooling here, not
the kind of caching we employ which restricts redraws when no
movement is occuring.
This would also explain the speed difference zincuntrin is seeing.
Most likely his view is entirely dynamic, in which case PV3D's
optimizations stand out. Of course, this can change on a per case
basis, since if you would do no specific optimizing per engine,
different features stand out.
absolutely. And that is the bottom line with all of this - there are
differences in the engines, some of them may be more beneficial than
others for your purposes. It's horses for courses, you pays your
(non-existent) money and takes your choice. :)
Rob
On Mon, Mar 9, 2009 at 7:16 PM, Ralph Hauwert <[email protected]>
wrote:
Interesting,
Considering that your triangle caching system only works when
objects haven't moved in relationship to the viewport, this benefit
would only be apparent during those situations, right ?
PV3D is currently memory stable, and wouldn't consume more then
needed. The clipping system we have uses triangle caching, and
overall no difference is noticeable, in that case. That is based on
my comparison tests, though, so that might be biased.
This would also explain the speed difference zincuntrin is seeing.
Most likely his view is entirely dynamic, in which case PV3D's
optimizations stand out. Of course, this can change on a per case
basis, since if you would do no specific optimizing per engine,
different features stand out.
Regards,
Ralph.
On Mar 9, 2009, at 7:20 PM, Rob Bateman wrote:
Hey Zincuntrin
here's an inconvenient truths about the flash 10 drawTriangles
method - it is, in almost all use cases, slower than using standard
flash 9 drawing commands. the reason we use them at all is so that
perspective correct textures are possible - which can achieve speed
increases in other ways (such as not having to use the subdividing
algorithm in f9 for perspective correction). But if you do a
straight comparison, you will rarely see any benefit.
The one case where this is not true is when you use indices to draw
your triangles, which reuse vertex coordinates for neighbouring
triangles. But this is not the whole story, because there are a
couple of problems with this approach:
a) not only is the vertex coordinate reused, but the uvt coordinate
is reused as well. It is baffling why this should be the case, as
almost all modeling programs export a format that allows uv
coordinates to be polygon-dependent, and vertex-independant. In
draw triangles it is the other way around - so using indices
restricts your uv mapping to a non-standard form that will break
most imported models.
b) there is a common problem with all new methods in f10 that use a
long string of vectors values, and it is called marshalling.
basically this the name given to the process required to 'marshall'
your values into a single vector for processing in the method. In
tests carried out on the drawtriangles class, the marshalling
process for using drawtriangles with indices neatly removes any
speed benefit that would be gained. In fact, the marshalling
process is still a problem even if you don't use indices, because
you have to concat all your screenvertex values every frame.
However, this is at least a process that can be improved, and will
hopefully see some speed increases as the Flash10 branch matures.
@Ralph - you're absolutely right, the sorting process is no
different in Away3d and PV3D. Although one area where we do differ
quite a lot is in object pooling, which in Away3d is tied into our
triangle caching system. Afaik there is currently no equivalent
system in PV3D, which should mean that Away3d is better performing
when it comes to memory consumption and GC calls over time.
@Zincuntrin - if you compare the f9 version of Away3d with the f9
version of pv3d, there should be less of a difference in speed. I'd
also be interested to see what difference there is between the
Flash10 branch of Away3d and the cs4 branch of pv3d, using the same
drawtriangles methods...
atb
Rob
On Mon, Mar 9, 2009 at 5:33 PM, Ralph Hauwert <[email protected]>
wrote:
Actually, right now Papervision3D and Away3D have exactly the same
sorting options.
As far as I know, by default both PV3D and Away3D exhibit the same
sorting behaviour.
Ralph.
On Mar 9, 2009, at 4:18 PM, Peter Kapelyan wrote:
Can you also try this on your model
mymodel.ownCanvas=true;
I think the reason pv3d is faster is mainly because of it's poor/
simple Z sorting.
If you enable ownCanvas on your model, it should be faster a bit.
Let me know if it is any faster.
Also I hear enhancements to f10 are still underway, but I am sure
Rob can speak more about that.
-Pete
On Mon, Mar 9, 2009 at 8:02 AM, Zincuntrin <[email protected]> wrote:
I have compared Away3D "flash 10" branch with papervision "flash 9"
branch.
Using a model with aprox 2000 tris, I get 40 FPS with Away3D and 60
FPS with papervision.
I have digged into the code and I have seen that you are not using
the
"render batch triangles" feature of flash 10
(graphics.drawTriangles?), but instead, you are still using the
"triangle by triangle" approach, though using the
graphics.drawGraphicsData in flash 10.
Am I correct?
It would be nice, if possible, to know the future plan for flash 10
usage, for example: What are the expected performance gains? When
will
it be ready? etc...
Many many thanks
--
___________________
Actionscript 3.0 Flash 3D Graphics Engine
HTTP://AWAY3D.COM
--
Rob Bateman
Flash Development & Consultancy
[email protected]
www.infiniteturtles.co.uk
www.away3d.com
--
Rob Bateman
Flash Development & Consultancy
[email protected]
www.infiniteturtles.co.uk
www.away3d.com
