3
\$\begingroup\$

This question already has an answer here:

Me and some friends developing simple 3D rendering engine as practice for the university. We used Ogre 3d as prototype and now we are developing it from base

The engine is wrapped up in simple game that asks the user to select shape (circle, triangle, square...), color and dimensions and renders the image to the screen. It also enables to move and rotate the shape on screen using mouse.

We would like to test automate the view rendering. I could not find any test framework for this issue and I would like to know how 3D test is done in non manual matter

\$\endgroup\$

marked as duplicate by Philipp, Josh Nov 13 '13 at 20:38

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

  • \$\begingroup\$ I doubt rendering can be tested automatically using some Unit test framework, how do you determine if something looks "correct"? \$\endgroup\$ – concept3d Nov 13 '13 at 12:51
1
\$\begingroup\$

The problem is that 3d engines aren't required to output an exact image bit-for-bit. Some leeway is tolerated as long as the artifacts caused by it aren't visible to the viewer. A texture being 1% darker than expected is usually not a serious problem... usually. Under some conditions it might be a visual artifact. And that's the problem: It is hard to judge for an automated test which artifacts would be noticed by a human viewer and which are not. Still, automated tests can be used for simple sanity checks when used on very simple geometry.

What you could do is render some simple scenes and then compare the generated image with a reference rendering. That reference rendering could either come from another graphic engine (like your Ogre3d prototype) or be an earlier screenshots from the same engine (regression testing).

When some tests fail after a change to the graphic engine, a human tester should compare the output to the reference image and judge for themself if the new output looks just as good as before (or even better). When that's the case, the test should be changed to compare to the new, improved outputs.

Another thing you could check automatically are performance requirements. One such requirement could be that during a self-running demo (simulating a real sequence from the game) the frame-rate must not drop below 40 Fps on the test system. This is something you can test automatically. What you can't test is that the rendering is satisfying. But you can use such tests to prevent your developers from developing a game which looks superb but doesn't run properly on any affordable system until years after launch (hello Crytek).

\$\endgroup\$
  • \$\begingroup\$ If you think it's a duplicate, you should post your answer on the original question. \$\endgroup\$ – MichaelHouse Nov 13 '13 at 22:14

Not the answer you're looking for? Browse other questions tagged or ask your own question.