Starling objects should expose depth test parameters

[oddwhocanfly]

This is very usefull when custom 3D rendering occurres inside display object tree. Currently starling only calls Context3D.setDepthTest() inside of Painter.nextFrame() with some hardcoded arguments.

I suggest to add "depthWrite" and "depthTest" properties to the DisplayObject and RenderState similarly to "blendMode" property, so depth test state can be automatically set up and restored when necessary.

P. S. I already have almost complete implementation of this feature and will be glad to contribute it, if someone will find this usefull too.

[PrimaryFeather]

Hi Alexander, thanks a lot for the suggestion (and sorry for the late reply)!

You're right, it would make sense to add those settings to the RenderState. As you know, the RenderState is, with all the "pushing and popping", quite sensitive when it comes to performance, but we could add those settings into the _miscOptions bitField, and thus avoid any issues.

I wouldn't add those properties to the DisplayObject class, though. I think they are too rarely used to justify that. Anybody who makes use of this setting can do so in a custom subclass. (Just like culling is used at the moment.)

Would that work for you?

[oddwhocanfly]

Hello,

I agree, it might be an overkill to add those settings to DisplayObject.

function setDepthTest(depthMask:Boolean,passCompareMode:String):void It is easy to pack the first parameter to bit field, but the second one, flash.display3D.Context3DCompareMode, have 8 possible values!

May be there is a different approach to the issue. What I ultimately want from this is the ability to easily restore context state, i.e. set everything i changed back as it is in the current render state. So, the simplest solution would be to leave everything as it is, but expose setDepthTest() Painter call arguments as public constants.

What do you think?

[PrimaryFeather]

It is easy to pack the first parameter to bit field, but the second one, flash.display3D.Context3DCompareMode, have 8 possible values!

That's true for the culling property as well (in this case, 4 possible values), but I can store an index referencing that string in a 3 bit area of the bitfield. So that would be feasible!

On the other hand, the solution you described would already help in this situation, too. I'll think about it!

[oddwhocanfly]

Hello,

I have tried both solutions. The one with actual RenderState properties made code cleaner and seemed more logical. I can submit pull request shortly, if you see this as a good thing as well.

[PrimaryFeather]

Yes, by all means, a pull request would be appreciated — thanks a lot in advance! :smile: