Support manual render mode / advancing the render loop by 1 tick

[verekia]

Support manual render mode / advancing the render loop by 1 tick

[dghez]

+1 on this!

Have the control over how / when to render and render-priority is deffo something REALLY useful, with r3f you can can do

useFrame(() => {}, proprity)

that is super helpful, you can use the priority = 0 to override the internal render loop, you can use negative values and positives too. This is very helpful when you want some stuff happens after others :)

EDIT:
My two cents is that is something REALLY important when you start to get your hands dirty with advanced techniques, like using render targets, render different layers at different order, use a custom pipeline, stuff that at sooner or later you'll need :)

[andretchen0]

+1

I also like R3F's approach. It's simple and flexible and lets users roll their own loop order.

Related

Issue: #607
Discussion: #578

Obstacles

It seems to me that what's holding the current codebase back is the simple, practical current implementation of useRenderLoop. It has lots of good parts, but some downsides.

useRenderLoop is global, so something like this works:

<script>
import { useRenderLoop } from '@tresjs/core'

// NOTE: TresCanvas hasn't been created yet, but you can already ...
useRenderLoop().onLoop(() => {...})
</script>

<template>
  <TresCanvas>
  </TresCanvas>
</template>

Users seem to like that. Me too.

But the current implementation isn't linked to any particular <TresCanvas />, which has implications for update/render loops:

• #251 – perhaps related
• #252
• #595
• #607

It'd be really handy if we could both:

• tie useRenderLoop to a particular <TresCanvas />
• continue to useRenderLoop in <script>, before <template><TresCanvas /></template>, without having to e.g., use refs and wait for onMounted

So ... 👇

Feedback please

Here's a proposal for creating an unbound context in <script>, before <TresCanvas />.

Feedback on this proposal is very appreciated.

Other proposals are also welcome.

Status

However, for me anyway, big changes like in the discussion I linked to are on hold until after v4 is rolled out, unless @alvarosabu and the rest of the team decides otherwise.

[alvarosabu]

Implemented with the new useLoop composable available on v4 https://docs.tresjs.org/api/composables.html#useloop

[alvarosabu]

@verekia I think we should rephrase this ticket to Allow overriding the renderLoop fn since the render-mode functionality you describe is "Conditional Rendering" which is going to be available on #541 only stops the renderLoop from rendering but doesn't overwrite it or allow the end user to add its own render loop which correct me if I'm wrong that was the usecase you were mentioning right?

[verekia]

@alvarosabu It seems like the upcoming manual mode + invalidate method is exactly what I am after, yes :) I didn't realize conditional rendering included that mode. With this mode, people who need more control over their game loop will be able to advance rendering exactly when they want it without relying on Tres' render loop.

This ticket was not about making an equivalent of R3F's renderPriority, although it's a nice feature to have for people who don't want to roll out their own game loop but still want to organize some logic around Tres' loop.

Feel free to rename the ticket as you please or make a new one about allow overriding the renderLoop fn :)

[alvarosabu]

Hey there!

As @andretchen0 perfectly explained, we need to work on having the render loop tied to the specific canvas and not global, which would be a significant change that would open a world of possibilities to users.

This together with Andre's proposal of unbound context and plugins is on top of my list for next 4.x releases. I'm worried that the render loop one will create another breaking change that would postpone it to a future 5.x.

@andretchen0 do you think we could do it without a breaking change or it would be better to delay the release and add this to v4?

[andretchen0]

Hey @alvarosabu

@andretchen0 do you think we could do it without a breaking change or it would be better to delay the release and add this to v4?

I responded over here.