Hi Guys,
Saki, one last thing to consider: do you -want- to implement BFC? If I understand the spec, it's not mandatory and renderers that simply ignore BFC and render everything two-sided do produce correct output.
I mention this because the win of BFC is to reduce the amount of fill needed to render a model (by eliminating rasterization of the backs of primitives). The cost of BFC (besides your development time :-) is some amount of additional state change being communicated to the driver. (The amount of state change will depend quite a bit on your renderer and how it optimizes and pre-proceses LDraw files.)
So if your renderer is CPU bound and not GPU bound and your renderer's code structure will require a lot of driver calls to keep BFC set up correctly, it may reduce and not improve performance to have it.
(I am assuming from the spec language that the goal of BFC is optimization and not 'clever rendering tricks' because the BFC spec is authored to "allow cross-compatible LDraw files.")
Cheers
Ben
Saki, one last thing to consider: do you -want- to implement BFC? If I understand the spec, it's not mandatory and renderers that simply ignore BFC and render everything two-sided do produce correct output.
I mention this because the win of BFC is to reduce the amount of fill needed to render a model (by eliminating rasterization of the backs of primitives). The cost of BFC (besides your development time :-) is some amount of additional state change being communicated to the driver. (The amount of state change will depend quite a bit on your renderer and how it optimizes and pre-proceses LDraw files.)
So if your renderer is CPU bound and not GPU bound and your renderer's code structure will require a lot of driver calls to keep BFC set up correctly, it may reduce and not improve performance to have it.
(I am assuming from the spec language that the goal of BFC is optimization and not 'clever rendering tricks' because the BFC spec is authored to "allow cross-compatible LDraw files.")
Cheers
Ben