Irrlicht Engine

I'm trying to use XEffects VSM shadows with transparent materials, and I'm encountering a strange issue. It's probably easier to show it than try to explain:

http://i.imgur.com/kTOQd.png

Does anyone know why this would be happening? Looking at the source of XEffects it looks like it's made to ...

Ah, I see. Not exactly a bug per se, but I would still consider it something to change in the next official release as being unintuitive at best. Thanks for the explanation though!

A quick update that will hopefully be helpful in debugging this issue: If the lighting flag on the node is on and the material's ColorMaterial flag is set to ECM_NONE , the behavior is as expected, but the ability to set any material colors on the node is lost. Here is my new source and an example ...

The draw2DImage call is working as intended. Setting the last parameter to false ignores the alpha channel of the render target texture, which hides the issue at hand. The real problem is with the texture itself, as you can see in the second image I posted, which is a direct dump of the render ...

I've been playing with Irrlicht recently for a little game project of mine, but the strangest thing was happening when I tried to use a render target texture with an alpha channel: EMT_SOLID objects were rendering semi-transparent. I explored the issue a little on my own to (hopefully) verify that ...

Sure enough, you were right! I toggled back/front face culling and it works fine now. Funny that I don't remember the article mentioning anything about that.. Thank you so much!

Thank you! I've updated the previous post with a link that includes libIrrlicht.dll, so anyone who's interested can have a look. I did verify in my latest code that outerRadius is greater than innerRadius, and I'm not sure exactly what the shader is doing either, but it's taken directly from O'Neil ...

Okay, I'm still trying to resolve this problem, but I've made progress. I had made several mistakes in the way the parameters were intended to be used:


innerRadius and outerRadius were reverse such that innerRadius > outerRadius, duh.
v3LightPos is misleadingly named, as it's supposed to be a ...

Either one would be fine. The sphere in the picture is the outer (atmosphere) sphere. The inner sphere just has an earth texture applied for now, no shader.

I'm trying to implement the atmospheric shader from GPU Gems 2 ( http://http.developer.nvidia.com/GPUGems2/gpugems2_chapter16.html ) and I'm getting, well... Unexpected results:

http://i.imgur.com/4JDUA.png

Anyone know what I'm doing wrong here? The C++ is here:

http://codepad.org/w2QhmYJZ ...

The specific error you're getting is due to the fact that Irrlicht defines several member functions of the ISceneNode class that are "pure virtual" functions. This means that the compiler has been told to expect these functions to be defined in any sub class of ISceneNode, but they haven't actually ...

Also, remember that the top and the bottom parts of the sphere CAN'T be mapped to polar coordinates because they are triangles, not squares, keep in mind that

I've been thinking about this, and shouldn't it still be possible to map it in a sensible way, especially given that the texture is in ...

One last thing: The image of the default uv mapping I showed before was the "north pole," toward positive Y. The default "south pole" looks rather different:



Am I really just crazy or is Irrlicht's default mapping a little off?

Here's something interesting. added the following code to my main loop:


verts = (S3DVertex*) planet->getMesh()->getMeshBuffer(0)->getVertices();
u16* inds = (u16*) planet->getMesh()->getMeshBuffer(0)->getIndices();
for (u32 i = 0; i < planet->getMesh()->getMeshBuffer(0)->getIndexCount()-1; i ...

I hope this is the right place for this. I'm having a little problem texture mapping a sphere. I'm generating a polar mapped fbm texture at runtime and applying it to a CSphereSceneNode, but the problem is that the uv mapping for the poles seems to be off. A sample texture looks like this:

http ...