Irrlicht Engine

I had a similar problem. If you want to take on all the rendering responsibilities (i.e. don't use drawAll), it's not that much of a hassle. The thread was over at http://irrlicht.sourceforge.net/phpBB2/ ... hp?t=32045.

I haven't seen a consumer level fixed-function GL implementation that supports negative lighting (not that I check often).

As a quick and dirty fix (with the emphasis on 'dirty'), you can disable culling per node using ISceneNode.setAutomaticCulling(EAC_OFF).

http://irrlicht.sourceforge.net/docu/cl ... d2db28c5b8

This came up here with no really satisfactory responses:
http://irrlicht.sourceforge.net/phpBB2/ ... hp?t=32081

For anyone else who gets an error like this, errors on exit under windows are more than likely caused by memory handling errors. The problem is probably in your code. Writing into invalid areas of memory are a common cause: writing outside the bounds of an array, writing into deallocated or ...

That does seem like a funny design decision - wouldn't it be easier to deal with shadows on a static mesh than a dynamic one?

Anyway, just off the top of my head, and with no promise of results, there is a IShadowVolumeSceneNode:
http://irrlicht.sourceforge.net/docu/classirr_1_1scene_1_1_i_shadow ...

There's a thread over here:
http://irrlicht.sourceforge.net/phpBB2/ ... hp?t=32033
Where a guy has posted his mostly working camera/movement code twice. I'll let you do the rest.

Thanks. That looks promising.

Correct me if I'm wrong, but I can't see a way to enumerate the display modes using pure Irrlicht. Am I missing something? How are other Irrlicht projects handling it?

So you've got your movement smoothed out? Excellent.

There is a problem that will crop up in 10 years time with varying the update rate. Quake 1 (and 2?) apparently suffers from a problem where the frame times are so short that when coupled with floating point errors, the movement is considerably ...

I haven't looked too carefully at your example, but one really common thing that can happen is updating the thing you want to look at, updating the camera target direction and the rendering are in the wrong order. You can end up rendering where the target entity was in the previous frame. Try re ...

And one last thing for anyone else trying to do the same thing, you'll need to call updateAbsolutePosition() on the node manually since that gets called as part of the rendering process normally.

So the character should always face the target? Something that might help your googling is 'polar coordinates'. Also, you said 'but in a 3D space around a circle', so is it a circle or a sphere you want to move in? I think you're asking about a circle and that's what I'll base my answer on.

The ...

OK. I'm back in business the problem with the last code chunk was with the material. I was ignoring the read-only material flag - incorrectly. They updated (and functional) line is:
const video::SMaterial& material = node->isReadOnlyMaterials() ? mb->getMaterial() : node->getMaterial(i);
Thanks ...

Now I'm getting somewhere. The geometry is there, but it's black. I'll keep at it :-)

Here's the code I'm using (you'll notice it's quite similar to the render method of CMeshSceneNode):
void GTRenderable::RenderToDevice(IVideoDriver *driver, IMeshSceneNode *node)
{
IMesh* mesh = node->getMesh ...