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
