Resolved Long term future plan of SRP, URP and HDRP

Currently dots graphics has been built on top of C++ engine side OOP land graphics backend that it's not really a fully pure dots graphics solution. Any plan to implement a truly full pure dots graphics backend solution in future that will be built on top of engine side full pure dots graphics backend? Long time ago at 2020, official mentions something at below but still I really hope it will happen as a long term future plan.

Spoiler

 

Does official still have long term future plan to further improve performance to next level that implement full pure dots graphics solution from lowest level graphics backend until very high level i.e. URP, HDRP? If I understand correctly currently it's kind of weird that seems like graphics rendering going through a lot of pipeline when u are using entities graphics. So graphics rendering pipeline is like going through from lowest level C++ engine side OOP land graphics backend -> entities graphics -> SRP -> URP/HDRP. Or at least is there any near term plan to merge entities graphics ->SRP -> URP/HDRP rendering pipeline process into just entities SRP -> entities URP/HDRP in future?

 

Awesome. I'm asking this is because it seems like it's too much work to maintain so many different graphics rendering tech while need to make it always working properly at the same time. Btw from what I understand BatchRenderGroup is C++ engine side OOP land graphics backend. Does BRG currently already provides enough maximum performance from low end platform to high end platform that official expected? So if I understand correctly I guess official will stick to BRG for like at least 10 years before starting to reconsider implement C# pure dots graphics engine side backend that is not longer is C++ engine side OOP land graphics backend for high end platform but low end platform like mobile platform and web browser platform will have simple lightweight pure dots graphics backend i.e. project tiny?

 

I see. Just curious why this graphics need to be stay at C++ rather just C# with burst since I believe it will still have performance issue of interop between C++ and C# ?

 

I see. I think currently there's a still have this long standing issue that C# side have difficulty to sync with C++ side that if when implement / fix something at C# missing something that requires C++ then needs to wait for C++ to land it. It seems like the only way to really solve this issue is to make it fully to 100% dots C#. I think there's unity staff mentions that there's a lot of discussion about migrate more and more C++ engine side code to dots C#.

 

I see but what really want to say is if C++ side can move to burst c# as a package then u can just update the package without needing to wait for new unity version. It also means it it will not tied to specific unity version. I believe currently it's also the main reason why it's so hard to backport something back to old urp/hdrp version that any new major version of urp/hdrp is only support specific new unity version and no backward compatible with old unity version.

 

Any code that interacts directly with native graphics APIs (D3D, OGL, Vulkan, etc) must be on the C++ side. Burst code is basically fast self contained native code that interacts with very little outside of it, so it can't be used for that.

 

I see. What I mean is using burst C# to create C# binding for these native graphics API like how unity engine exposes C# Transform binding from C++ side . Then now u can implement all of graphics related code at C# and able to achieve wat u say at previous post. But not sure about the performance.

 

Awesome. Thin layer on the C++ above the native graphics APIs side do u mean BRG or there's even better solution work in progress?