After several days of experimentation i just wondered if there is there a way to create or modify RenderMesh components inside a Job that I’m not seeing ?
All my attempts so far have ended up against the same roadblock of not being able to assign data to a RenderMesh because reference types (specifically Mesh) aren’t allowed in jobs.
So is it only possible to do this from the main thread or am i missing something ?
While you cant access the data I thought you might be able to bypass this by using SetSharedComponent from an ECB but that was a dead end as you can’t create a new RenderMesh within the job or pass a RenderMesh component into a job because it contains a Mesh.
Presumably a custom rendering component is my only option then
Try to create a new chunk CD which contain your rendering data and use the new MeshData API ( blittable mesh ) to access it inside jobs.
But you still have to modify the Hybrid Renderer to use your new CCD instead of the SCD rendermesh.
Yes i already messed with MeshData trying to solve the problem, never done chunks as yet but that seems fairly well documented.
Modifying the Hybrid Renderer sounds a bit more daunting though, i will open it up tomorrow and have a peek.
Thanks for the ideas, its nice to have a new focus after 2 days of finding new ways to hit the same roadblock
Then take the “building blocks” of the mesh, like the vertices, the triangles, the UVs, as NativeArrays/OtherLongFancyOverlyDescriptiveName and pass them into the job? I’ve done similar already to “circumvent” the data limitations.
Gettting the Data into the job or modifying in a job isn’t the problem though, MeshData would work for that, filling the RenderMesh Component at entity creation is what i cant seem to achieve. Most examples I’ve seen all appear to be using their own Graphics.Draw based functions and I’m guessing this problem is one of the reasons why.
A new entity is created during a job from an Archetype with a typeof(RenderMesh), however it seems impossible to actually fill the Mesh field of the component in a job as you can’t have a reference variable type inside a job.
Im a little confused as to why the Hybrid Renderer is using a non-blittable data type considering its designed to work with DOTS, i was thinking of trying to adjust it to use MeshData instead of Mesh which would seem a much better option.
Unless you’re creating your own render approach using non shared component data, the Hybrid Renderer uses shared component data for RenderMesh, so you can’t set this is a job. AFAIK, the fastest way to set it is with EntityManager.AddSharedComponentData<T>(EntityQuery entityQuery,.... Yes it’s a sync point, but it’s very fast as it’s set per chunk and I think internally the query actually sets it in parallel, a thread per chunk. In general, I would think that for certain use cases it’s also faster setting data via an entity query rather than queuing up lots of unrelated changes on a command buffer.
While you cannot change SCD data in a job you can just overwrite it with a different Component using ECB.SetSharedComponent though right ? This is how I’m creating all the other components for the new entity and it works fine.
The actual problem is that the MeshRender component contains a struct that is not allowed in jobs, so its impossible to manufacture or pass the component into the job even though i can get all the data into the job via MeshData, that just seems to be a huge design flaw in a rendering system for a multi-thread based application
Anyways modifying the HybridRender looks a bit beyond my capacity so for now i just made a quick loop with entityquery in the main thread that picks up all the empty RenderMesh components and assigns data to them but this particular entity type could be created 100’s of times per update so not being able to jobify it fully is a bit disheartening
I thought for a minute they let us Update Meshes in job system. But allas, it’s just a struct we could of made ourselves using a BlittableArray full of vertex data structs. (Malloc allocation)
I use SetVertexBufferData mesh function which is fairly fast, but it’s still done on the main thread.