Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Refactor: local and farm rendering #159

Open
1 task done
antirotor opened this issue Nov 11, 2024 · 1 comment
Open
1 task done

Refactor: local and farm rendering #159

antirotor opened this issue Nov 11, 2024 · 1 comment
Labels
type: maintenance Changes to the code that don't affect product functionality (Technical debt, refactors etc.))

Comments

@antirotor
Copy link
Member

Is there an existing issue for this?

  • I have searched the existing issues and added correct labels.

Please describe the feature you have in mind and explain what the current shortcomings are?

Local and farm rendering is trying to use the same workflow, but with very different logic. Local rendering is expecting files to be already created before running publish, on the other hand farm rendering is "just" creating farm job - it is not processing existing files nor it is creating them.

Right now we are creating new instances from existing instance in collectors, deleting old ones but since it is splittled between different collectors that can run in different order, it is very fragile.

Suggested implementation?

We need to refactor CollectRenderInstances (collect_render_instances) and CollectUnrealRemoteRender (collect_farm_render) where new instances are created so it is more under control and the data is shared as much as possible. In CollectUnrealRemoteRender, there is a use of UnrealRenderInstance() to create render instance - but that one is used for different purpose than in CollectRenderInstances.....

Describe alternatives you've considered:

No response

@antirotor antirotor added the type: maintenance Changes to the code that don't affect product functionality (Technical debt, refactors etc.)) label Nov 11, 2024
@antirotor
Copy link
Member Author

Some of it was partly done here #165 but more work needst to be done.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type: maintenance Changes to the code that don't affect product functionality (Technical debt, refactors etc.))
Projects
None yet
Development

No branches or pull requests

1 participant