Three.js: Feature Request: onBeforeRender to skip rendering

[ninja-hub]

Description of the problem

Hello.

I'm wondering if we can add functionality so we can skip rendering of an object in the renderer.
so we can use onBeforeRendering to determine if we want to really want to render this or not dynamically.

Cheers.

Three.js version

• [x ] Dev
• [ ] r82
• [ ] ...

Browser

• [x] All of them
• [ ] Chrome
• [ ] Firefox
• [ ] Internet Explorer

OS

• [x] All of them
• [ ] Windows
• [ ] Linux
• [ ] Android
• [ ] IOS

Hardware Requirements (graphics card, VR Device, ...)

[SntsDev]

Isn't it enough to set its visibleproperty to false?

[takahirox]

To set visible=false in onBeforeRender() won't work
because the rendering processing is roughly

1. filtering object out the visible of which is false
2. onBeforeRender()
3. rendering
4. onAfterRender()

First step is the reason that visible=false object isn't rendered.
onBeforeRender() is called after filtering out so
setting visible=false in onBeforeRender() won't affect its rendering.
And IMO we shouldn't set visible=false in onBeforeRender() because
onBeforeRender() won't be called for that object in next rendering.
(Set visible=true back in onAfterRender() may be the workaround but
visible=false in onBeforeRender() doesn't work anyways)

BTW I'm just curious to know why you need this feature.
You can't determine it out of the renderer?
Could I have an example?

I'm wondering if we can add functionality so we can skip rendering of an object in the renderer.
so we can use onBeforeRendering to determine if we want to really want to render this or not dynamically.

[ninja-hub]

Hi. all.
Thanks for responding.
I don't want to change the visibility of the object but stops it from being rendered for optimisation reason.

For example, some objects suppose to be visible in theory but occluded by other object so no need to render it.
I know occlusion query does not work for webgl but it is there for webgl 2.
It is mainly about rendering optimisation.

Thank you.

N.

[pailhead]

Isn't this a bit of a paradox? As probably the biggest proponent of these events, i admit it's super clunky the way it's currently implemented, BUT, if you prevent something from being rendered, onWillRender doesn't really make any sense since it will never render?

Whatever happens in your scene, be it you moved a camera or an object, thats where you should do your logic and turn something off, it doesn't have to be within the loop that goes through and actually issues draw calls?

[ninja-hub]

@pailhead In general, yes, you want to sort out if you want to render something or not before. However, for occlusion query, it tests if it is occluded or not by depth testing. So test can only be done after some objects are already rendered. (objects are usually sorted in z distance and rendered in order to check if we need to render the current object). And that is why this check has to be done just before the rendering of each object.

[Mugen87]

I don't recommend to change the semantics of onBeforeRender().

Working with occlusion queries is something specific that needs to be handled by the application for now. Maybe we can adapt at some point something similar like BabylonJS's occlusion queries.

https://doc.babylonjs.com/features/occlusionquery

[leefsmp]

Why the topic was directed toward "semantics" whereas the initial request was asking to provide a way to use onBeforeRender to run custom logic on a per object basis, which could determine dynamically if an object needs to be rendered or not.

It's a quite different approach than setting visible=false. I would be interested in implementing some optimizations that allows the FPS to remain high when interacting with a model even if that means skipping rendering of some meshes.

Scenario: I'm dealing with a very large scene that represents a warehouse, contains multiple assets loaded from a glTF file generated from blender and compressed with Draco. When user orbits the model or performs other interactions I would like to keep a high FPS so it looks smooth, however discarding rendering of some assets if the frame budget has been reached would be ok.

If onBeforeRender would return a boolean indicating if rendering of that object needs to be handled or not, could that work?

[pailhead]

How about an onWillUpdate? I don’t think that onBeforeRender should return a Boolean.

[leefsmp]

Has it been logged as a feature request? I think onShouldRender or simply shouldRender would be more explicit IMO.

[Mugen87]

Why the topic was directed toward "semantics" whereas the initial request was asking to provide a way to use onBeforeRender to run custom logic on a per object basis, which could determine dynamically if an object needs to be rendered or not.

Because that's not the way onBeforeRender() is intended for. When the callback is executed, it's already settled that the object is going to be rendered. That's what I mean with not changing the semantics.

In any event, I think a new callback is not needed for this scenario. You can implement the logic that decides whether an object should be rendered or not (by setting Object3D.visible or Object3D.layers) on app level.

[leefsmp]

Let's assume I have 1000 meshes in my scene, a render is triggered due to user orbiting camera, after mesh 501 has been rendered, I could determine my FPS has been considerably degraded and I would like to discard rendering meshes [502 ... 999] so as the user keeps orbiting, panning, etc... the interaction is still smooth. Now he stops interacting the model and clicks and some controls of the UI (some DOM overlays or controls placed outside the WebGL canvas) or even just look at the screen, the logic can now trigger another render which will iterate through all the 1000 meshes and the complete scene will be rendered.

I don't see how visible and layers will allow me to control that at the app level?

[Mugen87]

I could determine my FPS has been considerably degraded

Can you please explain how you can reliably measure this? According to my experience, working with time budgets in WebGL/JavaScript is very difficult because a lot of factors that you can't control and measure affect the final frametime.

Hence, in most cases it's more pragmatic to evaluate the frametime _after_ a complete render and then decide to lower/increase the amount of objects you are going to render.

But yes, if you want to do this in between a rendering a new API would be required.

[leefsmp]

I don't have a prepared solution for that, sorry to disappoint :) I was just investigating the field to see if something has been done in that direction with three.js and I stumbled across that request here.

If you need an example, the Autodesk Forge viewer can handle very large models and maintain a very smooth FPS, they implemented that kind of approach that they call "progressive rendering" and it is extremely efficient when interacting with BIM models containing massive amount of elements. The major inconvenient is that they forked three r71 and customized the whole rendering pipeline, migrating current three.js examples & features to make them compatible with such an old version has become a major headache when using it.

[makc]

after mesh 501 has been rendered, I could determine my FPS has been considerably degraded and I would like to discard rendering meshes [502 ... 999]

you can always do that in the next frame

[leefsmp]

Thanks, I was thinking such adjustment had to happen during a render but seems more reliable to handle after as suggested.

[pailhead]

Yeah, what you described, I think you’d have a lot of trouble tracking. Most likely, attempting to measure the time would actually cause more of a performance drop than just rendering stuff.

Adaptive rendering can be a bunch of things. When you start navigating with the camera you could turn each object into a bounding box. You could also render this via instancing, so your pans and orbits could be very very smooth. Once you stop, you could render the real stuff back in over a few frames. It would make more sense to limit it to a number of draw calls, than time it.