I just started using Away3D (specifically, I’m using the latest fp11 release on github) and am finding that Sprite3D entities aren’t culled correctly against the view frustrum.

I found the github issue where this bug is reported, but there’s not much response: https://github.com/away3d/away3d-core-fp11/issues/92

Until this bug is fixed, is there any workaround? Like, a spot in the code where I can tell the renderer to simply always render the sprite and not check it when doing culling?

Hey there,

I can confirm that behavior. When looking into the Sprite3D class I see that the method updateBounds does not take any scaling into account. As the geometry of Sprite3D doesn’t change at all but is only scaled when width or height are set, the bounds do not get updated and hence culling of a Sprite3D occurs already once its very center square meter is outside the view port.

I hack fixed it by additionally overriding methods set scaleX and set scaleY and accounting for scale in updateBounds:

Try this, let me know if it works =)

Cheers!
Alex

Thanks I’ll give that code a try.

(btw that delta strike spaceship looks pretty cool)

ADDITION: Darn, that doesn’t seem to have changed anything. Although, I’m not using scaleX() or scaleY(), I am setting the size in the constructor, so perhaps I need to make a change in there too.

Also, I turned on .showBounds and see a big flattened sphere. That seems odd.

Eventually my colleague determined that the default bounding sphere that is used isn’t culled properly by Away3D, so an easy fix for the issue is to simply set the bounds to an AABB:

sprite.bounds = new AxisAlignedBoundingBox();

Presumably the Away3D developers should just put this in the sprite code as the default setting.

Yes, I filed an issue about this awhile ago as well.

https://github.com/away3d/away3d-core-fp11/issues/55

jhocking,

yeah, right, sorry, my bad =)

I missed to mention that you will have to NOT use the width and height properties / constructor arguments, but use scaleX and scaleY instead.

But it would work both ways. If you change the setters for width and height the same way I did with the scale properties (invalidating bounds by setting _boundsInvalid = true;) then you need to take _width and _height into account in method updateBounds() as well.

Could be as easy as:

bounds.fromExtremes(-_width * .5 * _scaleX, -_height * .5 * _scaleY, 0, _width * .5 * _scaleX, _height * .5 * _scaleY, 0);

The thing you need to know about Sprite3Ds is that their geometry is created only once and shared among all instances. Setting width/height or scaleX/scaleY only affects their transformation matrix, which is individual for each instance. updateBounds(), however, does not take that transformation into account, which is why Sprite3Ds get clipped too early when their size / scale has been increased.

Cheers!
Alex