Adding Scanline Rendering Option
Nooop
scanline rendering, and what would need to be done?
It would allow higher framerates if smaller windows are used.
Peter Kapelyan
-Peter
___________________
Actionscript 3.0 Flash 3D Graphics Engine
HTTP://AWAY3D.COM
Peter Kapelyan
From any other rendering methods thus far (experimental or not), there has not been any increase in rendering speeds. There have been some tries with Pixel Bender, I would love to see a PB solution that's even a tad bit faster.
I think the best bet may be to wait for what Adobe has in store for us (they will announce at Adobe Max). It will be well worth the wait, and what I've been really waiting on myself. We should finally be "playing with power".
-Pete
Nooop
> Sorry, what I meant to say is "you can try if you have the courage".
>
> From any other rendering methods thus far (experimental or not), there has
> not been any increase in rendering speeds. There have been some tries with
> Pixel Bender, I would love to see a PB solution that's even a tad bit
> faster.
larger window, but in a very small window it could have a faster frame
rate. I think it is limited by the number of pixel.
Quake Flash probably using scanline rendering with a good frame
rate:
http://www.silvergames.com/game/quake-flash/
"Wire Engine 3d" has a scanline rendering option.
http://www.3key.at/we3d/forum/
2600 polygon flat shaded model in a tiny window and a smooth
frame rate:
http://www.3key.at/we3d/w3sample.html
15,000 triangles with scanline rendering:
http://3key.at/we3d/forum/demos/demo1/index.html
Flat shaded helicopter model:
http://3key.at/we3d/src/samples/1.html
Peter Kapelyan
Ken Railey
David Lenaerts
David Lenaerts
Flash platform developer
http://www.derschmale.com
Ken Railey
Joshua Granick
Perhaps you've been frustrated to find that the minX, maxX, etc.
properties don't seem to work properly? I've been loading up some models,
and the bounding box has been huge. At first I thought it was an issue
with how I exported the model, but later I realized it was simply how
Away3D was handling the dimensions.
After digging a bit more, I did discover that the Mesh object does report
these values correctly. However, once you attempt to check an
ObjectContainer3D, all bets are off. I'm sure this is for performance
reasons, but I think it would be awesome to have a "real" min/max value
available. Perhaps there would be some way to have a "dirty" flag, so it
wouldn't have to recalculate this too often? I know that once I load my
models, I'm not scaling them or altering the geometry, so it would be
great to have a reliable objectWidth value I could use.
Well, in lieu of this being a part of the core, I decided to build a
getObject3DMinMax function. I know it isn't perfect ... the values broke
down somewhere as I was trying to get the correct absolute min and max
values, but I was able to reliably get the object dimensions, at least in
my project. I wanted to share this code for the benefit of others, and who
knows? Perhaps someone could improve on this a bit more, or perhaps a
similar feature may find its way in the core.
Here is my function:
package com.eclecticdesignstudio.utils {
import away3d.containers.ObjectContainer3D;
import away3d.core.base.Object3D;
/**
* @author Joshua Granick
*/
public function getObject3DMinMax (object:Object3D, metrics:Object =
null, offset:Object = null):Object {
if (!metrics) {
metrics = { minX: Infinity, minY: Infinity, maxX: -Infinity, maxY:
-Infinity, minZ: Infinity, maxZ: -Infinity };
}
if (!offset) {
offset = { x: 0, y: 0, z: 0 };
}
//offset.x += object.transform.tx;
//offset.y += object.transform.ty;
//offset.z += object.transform.tz;
if (!(object is ObjectContainer3D)) {
if (object.minX + offset.x < metrics.minX) {
metrics.minX = object.minX + offset.x;
}
if (object.maxX + offset.x > metrics.maxX) {
metrics.maxX = object.maxX + offset.x;
}
if (object.minY + offset.y < metrics.minY) {
metrics.minY = object.minY + offset.y;
}
if (object.maxY + offset.y > metrics.maxY) {
metrics.maxY = object.maxY + offset.y;
}
if (object.minZ + offset.z < metrics.minZ) {
metrics.minZ = object.minZ + offset.z;
}
if (object.maxZ + offset.z > metrics.maxZ) {
metrics.maxZ = object.maxZ + offset.z;
}
} else {
for each (var childObject:Object3D in (object as
ObjectContainer3D).children) {
metrics = getObject3DMinMax (childObject, metrics, offset);
}
}
return metrics;
}
}
As I said before, it is returning the correct dimensions, but not the
correct position. Since the objects in this project are fortunately
aligned to their center, I was able to get the true min and max values by
using the function like this:
var dimensions:Object = getObject3DMinMax (object);
var objectWidth:Number = dimensions.maxX - dimensions.minX;
var objectDepth:Number = dimensions.maxY - dimensions.minY;
dimensions.minX = object.x - objectWidth / 2;
dimensions.maxX = object.x + objectWidth / 2;
dimensions.minY = object.y - objectDepth / 2;
dimensions.maxY = object.y + objectDepth / 2;
If you have any ideas or improvements, please reply to this message, so we
can all benefit. Getting the correct translation for the min/max, and
maybe some changes to support rotation values (not sure if its necessary?)
would be cool.
Thanks for any help, and I hope this helps someone!
Pascal Revillet
It basically works like a scanline renderer. My code was probably not
the most optimized code possible, but it worked rather fast, that is
about 200 or 300ms on a 512x512 texture. The bottleneck was clearly
ByteArray access which are really slow (a function call at each
access :( ).
You could probably do something faster which Alchemy, but I doubt you
can do anything 'usable' with scanline rendering in AS3.
As a matter of fact, as triangle is not hardware accelerated in Flash
player, triangles are rendered with a scanline renderer. As good an
AS3 implementation may be, I don't see how it could be faster than
Adobe's native implementation ;)
Pascal Revillet
On 13 août, 18:37, Ken Railey <ken.rai...@gmail.com> wrote:
> So even assuming fill rate could be just as quick using the fast memory copy
> from Alchemy, it still seems like the per pixel tests/writes will be a net
> performance loss, potential depth buffer notwithstanding :)
>
> -Ken
>
> On Fri, Aug 13, 2010 at 11:15 AM, David Lenaerts
> > A custom rasterizer has most chances using Alchemy so you can access fast
> > memory, and copy that from the ByteArray to BitmapData. That way, you could
> > also create a software depth-buffer or G-buffer at acceptable-ish extra
> > cost. It'd be an interesting exercise for sure, but I'm not entirely
> > convinced it'd be more than that :)
>
>
> >> I don't see why this type of rasterizer would be inherently faster than
> >> the current one. In most cases fill rate is the bottleneck, meaning that
> >> you want to get your pixels onto the screen as fast as possible. I would be
> >> very surprised if someone can find a way to do this faster manually in as3
> >> bytecode one pixel at a time than by using the internal flash bitmap drawing
> >> routines (written in somewhat optimized assembly, IIRC), no matter the
> >> window size.
>
> >> The window size is probably not even all that relevant, since *both*
> >> methods get faster as the rending surface dimensions decrease.
>
> >> Of course, I would be pleased to be proven wrong :)
>
> >> -Ken
>
Rob Bateman
again, these issues should be addressed in the latest svn updates. Although bear in mind that for performance reasons, any objectcontainer approximates its min/max bounds using the bounding spheres of its children
cheers
Rob
Rob Bateman
Flash Development & Consultancy
rob.b...@gmail.com
www.infiniteturtles.co.uk
www.away3d.com