AgentC

Yeah, was going to say the same what mhagain just said, are you transforming the vertices the same way in all lighting passes?

Also, if there are actually overlapping polygons in the same model, it may lead to double-lighting artifacts in light passes.

1) So, in essence, you're making code harder to follow by splitting it up at a very fine level, adding runtime overhead by adding superfluous virtual function calls, etc. just so that you can be typing code into an IDE *right this instant*? That seems a *very* poor tradeoff. This seems to be the thought process behind a lot of tutorials, actually.

EDIT 3: This kind of thinking is also what gave us JavaScript, FWIW.

 

2) Maybe in theory. By your own admission, though, there are often fundamental differences in how the API works that render this 'abstraction' meaningless anyway-- you still need to add more of them at different levels, which will in turn make code harder to follow.

 

3) Isn't the point of a tutorial to demonstrate how to take the low-level API and map it to higher-level constructs *anyway*?

Note that I was not trying to advocate a low-level abstraction, but to explain why such approach might be chosen. Like you said, tutorials are many times written without sufficient insight. A *good* low-level abstraction (if one can exist) certainly takes careful planning, and it shouldn't involve virtual functions

My view is that the Intel Smoke framework is somewhat over-generic (universal scene, which is extended with system scenes, change management) and some of its concepts are dubious, such as conflict resolution if several systems change the same property such as object transform (IMO that should not happen in the first place.) It doesn't really address the ordering of tasks within a frame, which doesn't hurt in the demo, but in an actual game it could lead to nasty non-determinism if for example AI is sometimes running one frame ahead, sometimes one frame behind in respect to physics. I'd consider it potentially dangerous if used directly as a basis for learning or for own engine.

I'd recommend, at least in the beginning, to be very explicit (even hardcoded) of what systems or tasks are actually running simultaneously, and what are the changes they're propagating to each other. For example physics updating object transforms, which the renderer picks up. Then profile constantly to discover the bottlenecks and to able to decide if threading will actually benefit them.

Some more resources (in case you're not familiar with them yet)

http://www.gamasutra.com/view/feature/1830/multithreaded_game_engine_.php

http://www.gamasutra.com/view/feature/2463/threading_3d_game_engine_basics.php

http://bitsquid.blogspot.fi/2010/03/task-management-practical-example.html

A few reasons I can think of:

1) it requires (at least superficially) the least amount of thinking / planning to just wrap the low-level API objects

2) by keeping the abstraction at low level you should, theoretically, be able to construct complex API-agnostic higher level rendering code, and not have to duplicate eg. the functionality of Mesh for different APIs

3) A tutorial stays more generally applicable if it doesn't impose its own higher-level constructs

It has potential to get messy, though. For an example here's a list, from my engine, of D3D / OpenGL differences that "leak" from the low level abstraction to the higher. It's not unmanageable, but not pretty either. https://code.google.com/p/urho3d/wiki/APIDifferences

It depends on the occlusion buffer dimensions.

On a 2GHz Core i7, I take less than 1 millisecond to rasterize 2000 triangles of terrain geometry into a 256 pixel wide occlusion buffer. Increasing the resolution to 1024 pixels also increases the time taken to 2.5 ms. My routine is depth only rasterization, and is not optimized to the max, C++ code only and no SIMD instructions.

I've found it hard to thread the occlusion rendering though, as the way I use it is a sequential operation: find out visible occluders, rasterize them, then use the result to check object AABB's for visibility.