IDEEN FÜR RYZOM

I'm not aware of any issues with shadows at the engine level. If there's a problem with object shadows missing or being wrong, it's possible that commercial Ryzom team is improperly spawning copies of lightmapped shape instances without lightmaps.

I probably don't quite understand it. Are there different versions of Ryzom?

Ryzom Core is the open source community project. But it's not really a game, it's just the base assets, all fully rebuilt from scratch, providing a blank shard.

If I record a video with problematic moments, can you confirm your guess?

Yes, please do send.

https://youtu.be/OPAblzk2PxI

The video perfectly shows the behavior of shadows. It can be seen that some shadows are "fake", some objects do not emit a shadow, and some objects pass a shadow through themselves.

Thanks. The only bug I see is the giant dark patch on the landscape at 0:28.

If there's dynamic objects not casting a shadow at all it's a bug too.

Regarding the dynamic shadows, they are rendered like a decal. It's a fake shadow. The decal is cast on the environment by the CPU, and it's only cast on landscape and construction (lightmapped) meshes. It's like generating a mesh that wraps over the environment to draw the shadow. (Shadow mapping wasn't really supported on a lot of hardware back when Ryzom was released, so this was a fair solution.) There's only one shadow per entity, so it's just averaged between the various lights.

Static objects will not cast dynamic shadow either.

The goal is not to look realistic, just to look good. It's an artistic choice.

Shadow doesn't cast on the fence, because it's spawned as a bot, rather than being part of the lightmapped construction. That's why the fence's shadow looks funny too.

There's no shadow on trees either, since those are instanced with dynamic lighting, and don't have lightmapped meshes (since they move), which excludes them from the shadow receiver as well.

It's not perfect or realistic, but in general if dynamic shadows are cast on landscape and indoors construction, it looks good already. Rendering is all just tricks, anyway.

I'm not opposed to implementing support for shadow mapping for dynamic shadows, or any newer techniques. It's possible to add a rendering pathway for that in the GL3 driver, but it's currently not a priority.

There's more to gain in improving the static lightmapper first as well, but then we need new tooling for landscape (indoors and outdoors) scene building too, since the lightmapper is currently tied into the 3ds Max export, and there are no other 3d modelers that can edit NeL landscape patch meshes, so we'd need to roll our own editor and scene placement tool.

It might be possible to include non-lightmapped animated character meshes in the shadow receiver as an option, but I'm not sure if the results will be useful. I'm concerned with the processing overhead on that. It's all CPU bound on a single thread. And even then, I'd rather upgrade the 3D engine to move character animation to the GPU to free up a lot of CPU waste, and at that point this option would be useless again.

We have a lot of nice-to-have ideas that are essentially useless if you build them because you need a dozen other things first to be able to effectively make use of them in reality. Or that would become useless again down the line because of other necessary changes.

(oops double post delete)

That is, in general, everything should be as it should be. Well, I was worried that there was a mistake =)
Then I can go back to other thoughts

Or learn C++ and OpenGL, and implement shadow mapping in the GL3 backend (after you finish missing features in the GL3 backend). :)

Lol, I appreciate your parting words on the right path, but I'm afraid it will take too much time =)