search

jnsmalm / pixi3d

The 3D renderer for PixiJS. Seamless integration with 2D applications.
https://pixi3d.org
MIT License
759 stars 44 forks source link

Loader to use name as identifier rather than url #103

Closed hypersurge closed 2 years ago

hypersurge commented 2 years ago

using resource name (rather than url) as unique identifier allows alternative loaders to preload the assets (e.g. with decaching query strings)

jnsmalm commented 2 years ago

using resource name (rather than url) as unique identifier allows alternative loaders to preload the assets (e.g. with decaching query strings)

Could you please provide an example so I can understand a bit more?

hypersurge commented 2 years ago

Example: Let's create or load a Texture Resource prior to Cubemap Resource (if loading, perhaps from a url other than specified in the Cubemap data). By assigning "name" to Texture Resource it can be easily shared to Cubemap's requirements, whereas "url" is one-to-one and may not be compatible.

Why is this impotant? Without it: 1) We can't rely on our macro loaders (they scrape contents from an assets folder, and we heavily reuse and combine resources) 2) We can't force decache assets at development runtime (e.g. by appending params / timestamps to urls)

In summary "name" is the unique indentifier, whereas "url" is the location of the resource. So logical filters should be done on the unique identifier ("name"), which may or may not be the same as location ("url") dependent upon use case.

Hope that helps, I accept our specific use case is probably of minor concern to anyone else so have tried to justify in more abstract terms.

jnsmalm commented 2 years ago

You are free to spend your time however you want 👍

hypersurge commented 2 years ago

I will spend another minute of my time highlighting the outcome because I am grateful for the groundwork you have done. By rejecting this PR you chose to have a 3D lib incapable of creating a Sphere primitive or off-loading Cubemap or Gltf assets because of a religious topic.

By arbitrarily and inconsistently making a non-documented, non-essential approach mandatory for reasons of personal style you close further contribution - forcing a fork is self destructive to an open source project.

A polite reminder - when someone takes an open source project seriously enough to contribute and explain their longer term motivations, the response should always be: cool, let's keep the momentum going :)

jnsmalm commented 2 years ago

I appreciate people wanting to contribute, but won't accept random stuff copied from another project without changing the style of it to suit the API more.

hypersurge commented 2 years ago

That doesn't relate to the Loader fixes as they have no new API. Style is subjective, if it was critical then it would be a) documented, b) consistently implemented throughout the lib, c) important enough for everyone to role up their sleeves.

Evaluating, bug fixing, porting, enhancements, highlighting inconsistencies, dialogue - these are all contributions, where's that appreciation you mention?

jnsmalm commented 2 years ago

Yes, we can merge the resource stuff. Please create a new PR and also add a test case for the functionality you have changed. You can copy the test from https://github.com/jnsmalm/pixi3d/blob/develop/test/gltf.test.js and change it so it works with your case. Also edit https://github.com/jnsmalm/pixi3d/blob/develop/test/index.js to include the new test. Run tests with npm run test.