Tell me about turso3d

[chrischtel]

Hello!

I’m really enjoying the current state of Turso3D and plan to work on it more frequently.

Before I dive in, I was wondering if you have a roadmap or a specific list of planned features? I have a few ideas of my own that I would love to discuss with you to see if they fit your vision.

Thanks, Christian

[cadaver]

Thank you for asking!

I work on this when I feel like it, the main thing that inspired me some time back was to get forward+ and automatically working hardware occlusion culling going.

Considering that I originally authored Urho3D, and it contained a more complete set of subsystems including audio and physics, I necessarily do not feel like replicating all the work here, since it ended up being a huge work. So it may well be like the front page warns that this will end up forever being a "toy" engine codebase, and I'd warn against expecting too much from this.

The threading is not yet quite how I would like it, because the rendering cannot be fully separated into its own thread. Changing that will however be quite a rework, if it's to be done cleanly (consider how e.g. Unreal needs to have separate proxy classes for the render thread)

It would be fun to be able to run e.g. the Urho3D example game NinjaSnowWar on this codebase, that would require at least physics, audio and some rudimentary UI element classes, but time will tell.

[chrischtel]

Hi Lasse,

Thanks for the reply!

About the threading: My idea would be a frame-snapshot approach. Maybe just double-buffering the render data with one-frame latency? It avoids the proxy classes. Also, I'm curious: what are the main mistakes from Urho3D you want to avoid here? (I looked at issue #2 and thought I'd ask).

I’d love to help. Feel free to create issues or a todo list so I can see where to start!

Best, Christian

[cadaver]

Yes, the double buffer approach will get you quite far. There may be yet issues with GPU resources, ie. if a game logic thread creates a texture and fills it with data, and perhaps is even silly and destroys it then on the same frame, that there are no crashes then. Maybe operating on handles instead of objects, or creating a command queue similar to bgfx will help.

In general the idea is to write a simple and performant engine codebase with maximum bang for buck, avoiding unnecessary data abstractions when an imperative code-based approach is more straightforward (you see that in the example application SSAO effect, there is no renderpath abstraction but just direct render commands with a specified shader and parameters).

The scene is also a pure node graph instead of components contained in nodes. I suspect that porting NinjaSnowWar would be enough to test the approach's total feasibility, and naturally the application can keep its own "game" objects (which could be component-based) instead of having everything living in the scene graph.

Thanks for the offer!

[uvwz]

Maybe you can take a look at this, it has a lot of cool features

https://trello.com/b/WzD2bYCD/arcane-rendering
https://trello.com/b/Giv16bRX/arcane-engine