Phew! GSoC is over. It’s been rough. A lot of fun. I’d hope it could last 3 more months, and we would get Ogre in an awesome state. Well, back to our weekends-only contributions; though I’ll probably be making a few more commits as I’m still accelerated and with some […]
Threading results were disappointing. Well, I was expecting 4x improvement on my quad core machine. The result was between 35-40% improvement which is still something. After a closer look, I ended up concluding that at 250×250 instances we’re memory bandwidth bound (i.e. disabling all math in UpdateAllTransforms and just doing […]
In Ogre 1.x; each Entity has it’s own list of lights, sorted by proximity. This way, when rendering, each Entity sends to the shader the closest N lights and, given enough batches, 8 lights per batch would be enough to lit the whole scene. That’s in theory at least. Until […]
So, I hit my wall against the head for two days… err my head against the wall, as I couldn’t solve a design problem with shadow mapping. I kept fixing an issue, cleaning what shouldn’t be necessary, then the compiler suddenly complains of yet another problem. For some reason I’ve […]
Originally, my idea of an elegant method of rendering a scene with shadow maps resulted to be flawed: That looked perfect until I stumbled with the problem that shadow maps’ directional lights need bound data from the original scene (namely an aabb enclosing all visible objects by the viewer’s camera, […]
Again, just like my previous post, I’m biased, it’s not strictly scientific benchmark, may not represent real world performance, blah blah blah. You know the drill. Move on. Now that I’ve done the proper disclaimers. Let’s get to the test. The test The test is similar to the one performed […]
There’s a lot of mysticism regarding inline & __forceinline even thought it is documented. What Microsoft tells us is that __forceinline turns off cost/benefit analysis of inlining, and tries to honour the developer’s request (note that it tries, it can’t do that always). Often developers are told the compiler knows what’s best […]
There’s a lot of memory waste in a MovableObject, just to name a few: The first two take 2 bytes per and cause lots of branches and cache misses (if visible && getCastShadows…), and the third one while it doesn’t take extra ram, it’s a nasty call stack of virtual […]
I”ve uploaded ODT & PDF slides with a brief overview of how the Memory Managers in Ogre 2.0 work (NodeMemoryManager & ObjectMemoryManager) so they don’t look so black box magic. I wrote them while I waited for Ogre to compile (and I do that often…). It doesn’t take too long, […]
…and I’m biased like no one! Now that I’ve got your attention with such pretentious title :), let’s clear a few things: This is an unfair comparison. More than half of Ogre features are disabled (because they do not compile or would crash). It’s possible that adding them back could […]
