Irrlicht Engine

Also to note, the OnAnimate for the CBoneSceneNode is overridden and the updateAbsolutePosition is currently commented out. This makes it impossible to have position up-to-date for child nodes because the joint is always one frame behind on updating it's position inside OnAnimate from inside the ...

In Irrlicht 1.8, If I attach scene nodes to an CAnimatedMeshSceneNode joint and move the scene around, the attached scene nodes seem to look like they drag behind.

I traced the issue to the OnAnimate( ) function. When OnAnimate is called... it calls getMeshForCurrentFrame() and inside that function ...

The Irrlicht creation params just take a number of the samples used for anti-aliasing. The enum is for the materials, which can enable or disable AA per scene node.

Yeah that's what I was setting. AA is just weird for me in OGL, I seemed to remember having issues finding the right settings in the ...

Mel wrote:i never got antialiasing working with GL

Ah, yes, I tried D3D9 and it renders with anti-aliasing. So it's an OpenGL thing.

From the snippet below I thought that SIrrlichtCreationParameters::AntiAlias variable was to set the power of the anti-alias.. or the multisample power.
//! Specifies if the device should use fullscreen anti aliasing
/** Makes sharp/pixelated edges softer, but requires more
performance. Also, 2D ...

SIrrlichtCreationParameters irrparams;
irrparams.DriverType = FDriverType;
irrparams.Bits = 32;
irrparams.Fullscreen = true;
irrparams.Stencilbuffer = FShadows;
irrparams.Vsync = FVSync;
irrparams.AntiAlias = (FAntiAlias)? 8 : 0;
irrparams.ZBufferBits = 8;
irrparams.LoggingLevel = ELL ...

cube->remove();

... should do the trick most of the time

VSpace - San Francisco Intl Airport Night Scene 120 degree view

click the image to enlarge

No, the mesh cache can also contain other types of animated meshes.

I guess that this wrong usage anyway, trying to remove a mesh from the mesh cache but actually using the pointer to animMesh->getMesh(0) rather than the original animated mesh pointer. Perhaps not a bug after all, maybe a doc ...

Sounds like you've found a bug, removing the mesh should work. We only added removeUnusedMeshes for people who have a huge scene and wanted to clear down their cache (it removes all meshes with a reference count of 1, ie, those which belong only to the mesh cache).

If the size of the mesh cache ...

Interestingly enough, when I switch to D3D9 I get the opposite effect. Instead of over lit it's under lit, like almost completely black on any mesh that has lighting enabled.

This might be a pretty easy fix but I'm not sure what I'm doing wrong. When I run my 3D code from a box with an NVidia GForce card the lighting looks nice. When I load the same code from an ATI card the lighting looks horrible and over lit like the attenuation was jacked with.

Anyone else ever have ...

It looks like for now the changeWorkingDirectoryTo(...) function only applies to FILESYSTEM_NATIVE, in the function it checks which filesystem is active but when a file is attempted to be opened in an archive the working directory is never applied to it.

So I would have to go through all my meshes ...

I forgot to mention... this code includes support if the model is in a native directory as well. That is why there are so many calls to setting the working directory.

Also, if I specify the entire VIRTUAL path of the model, the images don't load because the images in the mesh don't have relative ...

I am trying to load a mesh from a ZIP archive. It seems that the archive code doesn't apply the VIRTUAL working directory when searching for the file in the archive. In the archive it's "media/modelname/model.x" and the images are in the same directory. When I debug I never see the VIRTUAL working ...