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

Removed RaytracingRenderer #18283

Merged
merged 1 commit into from
Jan 1, 2020
Merged

Removed RaytracingRenderer #18283

merged 1 commit into from
Jan 1, 2020

Conversation

mrdoob
Copy link
Owner

@mrdoob mrdoob commented Jan 1, 2020

No description provided.

@mrdoob mrdoob added this to the r113 milestone Jan 1, 2020
@mrdoob mrdoob merged commit 7c5a46a into dev Jan 1, 2020
@mrdoob mrdoob deleted the raytracing branch January 1, 2020 17:36
@EliasHasle
Copy link
Contributor

EliasHasle commented Jan 3, 2020

Presumably to focus the scope of the library? Will the RaytracingRenderer migrate to somewhere else?

@Mugen87
Copy link
Collaborator

Mugen87 commented Jan 3, 2020

It seems it's better to implement such a renderer on top of three.js in a separate project e.g.

https://github.com/erichlof/THREE.js-PathTracing-Renderer

@donmccurdy
Copy link
Collaborator

See issues like #18277, too... the raytracing and deferred renderers were incomplete or proof-of-concept-ish in ways that made them impractical for real use, IMO. It's hard to communicate that expectation to users — many things in the examples/* folder are production-ready, and some (loaders, controls) are practically indispensable for many projects. And maintaining multiple production-ready renderers would be a huge undertaking. So I think removing them probably helps to steer users to the more reliable workflows.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants