Make yourself aware of API limits and how Urho uses those limited things. From my own experience blowing the D3D11 SamplerState limit before with scores of tiny 16x16 textures before I fixed it as a table in a fork.
View, Renderer, and RenderPath are your danger-zone classes. Everything you touch there is likely to have serious consequences or balloon in the scale of changes required beyond what you might imagine.
Code search for the WorkQueue
so you know what’s already jobified so you don’t do something stupid trying to jobify things that are already jobified in some fashion elsewhere.
Balance your script and C++ code usage. Some tasks like those that touch crowds and physics events are better suited for C++ than Angelscript/Lua.
There’s a handy-dandy WriteDrawablesToOBJ
capability that you can use to dump your scene/geometries to OBJ so you can use it as a reference in other tools (or for other purposes like static-batching). This is useful when you need to generate geometry in other tools like Houdini or just fitting some spline generated extrusions in Blender.
Beware that the async loading is actually brittle as hell. If there’s a pending async load you have to force it to finish before queueing a new async load. You can quickly tweak that to pump asyncs into a vector though and cycle through them for each step of the async load. If you intend to use async load, then you MUST modify the function to accept a destination Node. It’s borderline unusable without it as you can’t dump async things out if you don’t have a holder for them.
Edit: Urho is also not setup for texture streaming. If you need that you need setup your own file scheme for how you load mips from bottom to top instead of the usual top to bottom and setup the sampler LODs appropriately to cap the miplevel.