I was looking into a faster way to render fbos into rendertarget using the renderBufferDirect threejs method.
Got it working
this.renderer.setRenderTarget( prop.output );
this.renderer.objects.update( prop.mesh );
this.renderer.renderBufferDirect( this.camera, null, prop.mesh.geometry, prop.mesh.material, prop.mesh, null );
But it needs this object :
https://github.com/mrdoob/three.js/blob/dev/src/renderers/WebGLRenderer.js#L286
to be exposed as a property of the renderer in order to update buffer attributes.
It could help to render objects and fbos immediately without using the whole render function.
And also help to speed up post-processing effects method !
Is it worth exposing it ?
[ ] ...
[x] All of them
[ ] Internet Explorer
[x] All of them
@mrdoob what do you think ?
Totally agree to add more control on the render system of threejs in general for advanced user/uasge.
I wouldn't expose it directly...
Maybe build an API on top of it? renderer.getInternalProperty( value )
?
I'm perfectly fine with this idea !
It would give more control and usage for advanced users !
@mrdoob @Samsy
any progress on this?
I found myself in the need of this functionality also. More specifically, i'm trying to modify shadowmap after it has been generated, but before the main rendering pass.
@mrdoob any though on this one ?
I had a use-case recently.
I used some custom functions to render faster into targets / on screen for post-processing usage without going through all the render function. It could even be lighter and faster than this with more controls.
It could be nice to access as you suggested internals values of THREE.JS using an API.
It could potentially help people build plugins and custom things on top of it without writing in the sources.
Many thanks for your time @mrdoob
If this is still needed (looks like it may be) I could make a PR with the renderer.getInternalProperty( value )
API.
I need this too. I'm trying to do something similar to a standard vertex buffer for 2d hud items. I want them to be drawn immediately after the call, not when the scene renderer renders them. I can't do that at the moment as the buffers never get created, as this is done in the scene traversal code (via objects.update(object)).
@mrdoob I do not recommend to open up the renderer in the suggested way. The more internals are exposed (even via methods), the harder will it be to refactor and optimize the renderer in the future since users will rely on certain assumptions.
I think it's better when above uses cases are realized when projects fork and modify the renderer according to their use cases.
Most helpful comment
I wouldn't expose it directly...
Maybe build an API on top of it?
renderer.getInternalProperty( value )
?