This blog’s been a bit silent the past couple of weeks, but I haven’t been idling at all – quite the opposite. Even with fresh copies of Dead Space, Fable 2 and Fallout 3 laying too near for comfort, most of my free time has been taken up by Wick3d (1 | 2). Recent developments in Papervision3D and Away3D (the choices for commercial-grade Flash 3D) only made me more excited to do some extra studying and experimentation. Just to clear things out now – there won’t be any demos in this post, but I will mention what I’ve been working on, and hope to merge with the Wick3d repository sooner than later :)
- Lighting/Shaders: The old Wick3d (before I started over, that is) had some basic support already, but shading is going to make an improved reentrance.
- Correct Z-Sorting: a tricky one. Since a stencil (z-)buffer isn’t an option in Flash, the only way I know how to sort triangles correctly is the Newell-Newell-Sancha algorithm (an extension to the simple painter’s algorithm). However, since it’s an O(n²) algorithm it can slow down to a crawl rapidly with enough triangles. Organizing the triangles in a quadtree (similar to PV3D’s latest addition) could improve performance, but still – per quad – there’s the n² issue. I’m sure there’s better ways to solve this problem and I’ll keep up the research. Any tips on this subject would be most welcome, of course :D
- Working with the BSPRenderPipeline has been reworked and now supports dynamic objects moving about in the BSP tree (this one’s actually done, but not comitted to the trunk yet – check out the dev branch if you’re feeling brave :) ). Create a BSPWorld3D instead of a World3D, passing the static base to the constructor, and add dynamic children with addChildren as usual. A demo with source will follow soon, with some luck.
- Redone Collada support. It’s still very basic, no hierarchy, but parsing is much faster. It will be improved whenever needed. Parsing files is not my preferred pass-time, so I tend to keep it at this point until I personally need more support.
- Restructuring of certain parts of the engine. For example, Rasterizers are now classes on their own, so different types can be used in any render pipeline.
- Various optimizations and trivial updates.
- Thinking about FP10 and how I could harness the power of drawTriangles when dealing with (virtually) a polygon soup. I guess you’d still be drawing every triangle separately without sharing the vertices.
Heh, at least I’m not slacking off! ;) It might take a while before these updates are comitted to the main trunk, so I thought I’d give this rundown of things to come – hopefully! Any brilliant insights? Let me know :D
thumb up! cheers David! ;)
You have the maniacal perfomance to do changes :))!! Why you have decide to “Create a BSPWorld3D instead of a World3D”? For optimizing or differentiation of scenes?
@Foreground: There were a couple of reasons for that, actually, and most of them stemmed from the fact that I wasn’t really satisfied with how the flow went in the previous version. If you’ve seen it, it meant passing your bsp tree into the BSPRenderPipeline constructor, which didn’t make much sense as it’s not really linked to the pipeline as much as it is to the World3D – especially when combining it with moving objects. Since the BSP tree is useful for architectural things and static surroundings, it could be considered that it actually IS the world in which you’ll be placing dynamic objects. This way just made complete sense to me, while the previous method didn’t ;) Another reason was that I didn’t want to force people to have to create a BSPTree object since it’s more of a core scene graph. So you’d only pass a HierarchicObject3D/Model3D and the rest would be taken care of. Again it made more sense to use a World. So basically, it boils down to consistency: all 3D objects to be rendered should always be part of the World ;)
Now you’re busted, mister! ‘Part of your world’ is a song from the little mermaid. I always knew you had the hots for Ariel.
Haha, long time, Murten ;)
The power of drawTriangles was shown to be 0. People were having same performance as with good old moveTo/lineTo-s. There is a couple of threads at Adobe forums about it, or just ask papervision guys.
Hi Makc,
Yeah, as far as I know, using it in conjunction with uv-coords, it’d actually be a bit slower. The up-side is, however, that you don’t have to subdivide the triangles to make up for linear texture mapping, which makes everything before rasterization faster (and you definately don’t need to use rather slow realtime perspective-corrected subdivision). Another speed-up posibility is the fact that – similar to OpenGL – you can use it to draw triangle strips rather than seperate triangles. The problem with this is how to recognize triangle strips, because after z-sorting (which is still necessary since we don’t have a z-buffer) triangles leave the pipeline in quite an arbitrary position… A lot of food for thought on my end ;)
I’ve been quite busy the past few weeks, but since this last post I’ve had some time to work on some things (some issues that I deemed trivial became major), and I’ve been able to do quite a bit in a relatively short time. However, after that I became swamped with work, haven’t been able to do squat, and this past week I decided I needed to relax in my free time (and beat Gears of War 2) :D I’ll be back at it soon tho! (if now I can resist Fable 2…)