I made an extension which implements it’s own component class inherited from RenderComponent. This class handles rendering of geometry, which is integrated deeply with Cocos Creator and uses it’s materials and textures.
It appeared that the extension works only on Web platform and when I try to start an application on Simulator from the Editor, I don’t see any rendering.
So, my question is, should it work right away, or I had to make some additional work to achieve that?
Hi, I test your extension on master branch, but has some error, can you provide a finish version for me, so I could check you problem.
@huanxinyin I use latest stable version of the Cocos Creator. It’s 2.4.3. I re-checked on Windows 10 and with stock JavaScript engine which comes with the editor. Everything works fine and without errors.
Here is a sample working project with test particle effect:
SparksNoSimulator.zip (6.9 MB)
There are installation instructions on the gitlab extension page, if you want to install it manually. Also there are comprehensive documentation and tutorials if you have any other question on how to use it.
If you still have the error, could you post it here please or on the Issues page on gitlab. I’ll check it as soon as possible.
Hi, native renderer have different render flow, such as the conversion of world coordinates，you can understand the problem with this test project. test-example.zip (282.9 KB)
@huanxinyin I spent some time to understand how Cocos JSB works. And I became frustrated a little because of that render flow differences and architecture as well. The project you sent shows some tips of custom renderer based on Sprite2D, which has static geometry. But I have much more complex case, where geometry can be very different fame after frame. So for WebGL I worked with MeshBuffer directly (obtained from ModelBatcher) to fill it with geometry. Provided sample doesn’t show how to intensively use MeshBuffers. And it actually breaks render flow of the application, because if you add 2d particle system right after the node with CustomComponent, particle effect is not rendered until you delete CustomComponent.
So, for now I’m trying to find any usable sample of component for native renderer which would clearly show how to work with buffers and correctly inject assembler into rendering pipeline. Without luck yet.
Yes, you can try to implement base on MeshRenderer class on native platform, it work base on renderer.MeshAssembler, you can refer jsb-adapter code, and check how a MeshBuffer work on native rendering, you can debug to trace the flow.
/Applications/CocosCreator/Creator/2.4.4/CocosCreator.app/Contents/Resources/builtin/jsb-adapter/engine/assemblers/mesh-renderer.js
@huanxinyin I made it! It was close to a nightmare, but I did. Thank you for your assistance.
I made an assembler for CC_JSB inherited from MeshAssembler and I didn’t use MeshRenderer class as base of my NeutrinoComponent. Below are some questions and concerns regarding engine, would you be so kind to give short answers on those:
I wonder why Assembler, CustomAssembler and MeshRendererAssembler are not exposed to scripts? So we need to have the last one by ugly reference: cc.MeshRenderer.__assembler__.prototype
There are many other classes which can’t be accessible from the scripts, like MeshData, VertexBuffer and IndexBuffer. It makes impossible making assemblers with much more optimized rendering. Or maybe I just missed the way to use them?
Why the engine doesn’t have shared rendering pipeline? There are several classes which should be implemented in respect to the platform, but whole rendering pipeline could be the same. Like it’s done in most of engines. I saw how WebGL rendering goes in the Cocos, and it’s pretty good. There are shared batchers for geometry and many other nice features. And when you try to render something on other platforms, there is a completely different pipeline. Without documentation. Yes, it is open sourced, but those three parts: engine, jsb and native renderer make debugging and understanding of the engine dramatically slow and painful. So, now I finished with two different instances of code of NeutrinoAssembler, and I feel like I did the same job 5 times. Last four are for native renderer.
The code it pushed to the master branch, of the extension repository, and I believe it is now ready for use with 2.4 version of the Cocos on all platforms.
The next step is Cocos 3.0. Good luck to me.
Great! In order to improve the native rendering capabilities, we introduced new rendering code and compatibility with the original interface, so the situation you described, which was a problem, has been addressed since version 3.0.