IDEAS FOR RYZOM

I was paid (not much) for the basic shape exporter, and only for the milestone that exports static objects with standard materials. (And that was in 2015. Don't know anything about where you threw money in 2013.) It will also export any mesh format that's supported by Assimp to NeL format, not just Blender. Nobody has reported any issues with it so far, and it does what it's required to, so there is no need to be hostile on the subject.

When I tried getting sample models from the Forge team, for testing and proposing the next milestones, they never sent anything. Nothing. So I did not continue developing it further. (And from what I understand, Forge didn't even attempt to use it until 2017.)

The hypothetical tooling is just a scapegoat to blame for the lack of art contributions, and is just keeping people busy on things that aren't really needed and nobody really plans on using. Anyway, they'll just keep blaming hypothetical tools that they're missing. And being hostile to developers for not doing hypothetical things they hypothetically need.

I'd be happy to propose and work on further milestones if there were money AND artists to work with. Otherwise, there's no incentive for me at this time to proceed with tooling in this direction.


It's also automated and fully functional. (Except in commercial Ryzom, I guess?)


The solution is to ignore commercial Ryzom. Even if you put effort, they'll just make it difficult over and over again for those efforts to be integrated. Even if you hand them full integration of whatever you built on a silver platter, they'll redo the integration themselves if they ever get around it two years later, and break half the things in the process. And then they pretend they never saw, and ask for it again, just to ignore it again.

If everything would work well, they wouldn't have anything to blame as a scapegoat anymore.


Exit the system.


Grinding is the only mechanic that really made it to the game's release. Everything else was unfinished placeholder contents. But it does not define the dream of what Ryzom could be. And then at some point someone thought that fixing everything required a full reset, and then they did a pointless full reset without fixing anything thinking it's the reset itself that magically fixes things. Ryzom hasn't been anything like Ryzom anymore for a very long time now already.

The engine is not the problem.

Don't need millions. Maybe a couple 10k. We're already fixing a lot of the more technical issues for ARM target platforms. There's also a nearly feature complete OpenGL 3 implementation of the graphics backend, which can be developed further eventually to support any recent mobile OpenGL ES instead. I just finished implementing support for connecting the client over QUIC to allow wireless connection migration to work transparently.

UI would definitely need some revision, though. It'll be too clunky on mobile to capture a massive audience.

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.

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.

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 =)