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

Asset file prefix #316

Closed
frankxw opened this issue Jun 16, 2015 · 2 comments · Fixed by #411
Closed

Asset file prefix #316

frankxw opened this issue Jun 16, 2015 · 2 comments · Fixed by #411

Comments

@frankxw
Copy link

frankxw commented Jun 16, 2015

Would it be possible to add an optional url prefix for assets? Currently, this exists for scripts in framework_application.js:_preloadScripts scriptUrl = pc.path.join(this._scriptPrefix, scripts[i]);.

It would be useful to have another field in the Application options (or maybe reuse scriptPrefix?) for the rest of the assets loaded in config.json (materials, textures, models, etc.). This is useful if the URI does not match the file locations - for example, if your page is served as part of a REST API call, the content is likely to be stored at a different URI. This also allows static assets to be served from S3 or a CDN.

@daredevildave
Copy link
Contributor

I think that sounds reasonable. I'd probably add an new option to the AssetRegistry to append a prefix to the asset url.

This would assume that all assets are based in the same location.

@frankxw
Copy link
Author

frankxw commented Jun 17, 2015

I think that since there's already a structure to the export (files/assets/id), that it makes sense there would only be one location for all the assets. Splitting up the files directory, in my opinion, is not a likely case because it would bring a whole host of other problems - at that point you'd be better off using the engine directly instead of using an export from PlayCanvas.com

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 a pull request may close this issue.

3 participants