LDraw.org Discussion Forums

Full Version: Regarding rendering of parts
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Pages: 1 2
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
Ben Supnik Wrote:(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

This is correct. Any authored part that exposes the back side of a BFC component is considered a bad part and will not be allowed into the library.

Tim
Well my renderer will be running in a browser (WebGL + Javascript) in real-time, so I am trying to squeeze as much performance as possible without using double-sided faces. Actually without BFC checking the renderer works fine.

I just tried rendering 5541_blue_fury.ldr model with BFC off and on my laptop (quite old) I get 30FPS (frames per second). When I enable my semi-correct BFC checking I get 35FPS. So BFC checking for real-time renderers is worth it.
What renderer is actually doing the rendering? E.g. is this hardware accelerated, and if so, what is the GPU?
Yes it is hardware accelerated on an NVIDIA 9800 card.
So I know precious little about WebGL, but does it give you the option to do vertex buffers? That model renders just fine even on my iPhone, so it seems the bottleneck is likely more in the preprocessing and not the GPU.
I did not say it does not render fine. I only said that it is almost always the case (99%) that enabling backface culling will be faster.
WebGL does have vertex buffers which was my next task after determining correct bfc rendering.

By the way with which software are you rendering on the iphone?
Ah sorry. I meant I have no fps issues (albeit I'm capped at 15 fps I believe). It's something I'm designing myself, but it's via OpenGL.
Pages: 1 2