UpdateAsset.prototype.update = function(dt) {
var app = this.app;
if (app.keyboard.isPressed(pc.KEY_SPACE)) {
console.log(this.entity.model.model +" :A: "+this.a.resource +" :B: "+this.b.resource);
if (this.entity.model.model !== this.b.resource) {
// update the model component to the new model
this.entity.model.model = this.b.resource;
}
} else {
if (this.entity.model.model !== this.a.resource) {
// restore original model
this.entity.model.model = this.a.resource;
}
if (app.keyboard.isPressed(pc.KEY_C)) {
console.log(this.entity.model.model +" :C: "+this.c.resource);
if (this.c.resource) {
if (this.entity.model.model !== this.c.resource) {
this.entity.model.model = this.c.resource;
}
}
} else {
if (this.entity.model.model !== this.a.resource) {
this.entity.model.model = this.a.resource;
}
}
}
if (app.keyboard.isPressed(pc.KEY_L)) {
app.assets.load(this.c);
}
};
The output gave three ‘of the same’ in the comparison (this.entity.model.model => [object Object] + this.a.resource => [object Object] … likewise for this.b ).
I do not find that comparison to be working in all cases >> fx while using .enabled = false to .enabled = true instead of (as in example) app.assets.load(this.c);
I tried to use the example without the top editor asset assignment - as otherwise seen here:
Which ultimately makes me suggest that the following structure should be added to/found in the example as well:
var someEntity = this.app.assets.find("someUploadedModel.json");
this alternative ‘direct-in-assets’ use of finding the asset, is then tested for .loaded with a true/false comparison instead:
if(someEntity.loaded ===true ... etc
This approach works on non-preloaded models, being runtime event-rendered (from .enabled = false to true), also.
The example could make some emphazis on why the [object Object]-comparison works sometimes (as in present example and not-always while used in a .enabled = false to true setup)
It is a post under ‘Suggestion & Feedback’ … have already made a solution, but I am suggesting a more advanced tutorial (please read again for details)
Sorry, cannot do that at the moment … It is one of the more secret projects - and making a minor disclosed dummy is time consuming
But, hey - this topic is just a “suggestion” >> we can let it rest without a [SOLVED]
If a user choose to use the example, the user will find out that the comparison line: if (this.entity.model.model !== this.a.resource) {
seem to based on ‘more luck than factual; equality/unequality’ on both sides of the !==-comparer [hence: beneath the [object Object] the list can be anything, in theory … and not good for understanding PC-resources]
There is another way to work with ‘loading of assets’, and in my own example, I was trying to find out if an asset ressource is loaded, in relation to an event. The ‘Asset registry’-example actually also works with such events, but in a more deliberate way; as the ‘C’-letter model is tested for being loaded after a deliberate button-action [example should be optimized to make emphasis on this difference].
The ‘Asset registry’-example uses a deliberate approach, whereas my own approach is more dynamic >> using someEntity.loaded ===true (where, for instance, a crude update-listener can determine if a model is loaded, regardless of [obejct Object]-list details or button-interaction).
The !== checks if the left side and the right side are referencing the same object which is not luck based. This will always be true if they are both referencing the same object, and false otherwise. If you have an example where this is not the case, I would need to see a running sample.
Not sure what you mean by ‘deliberate way’
Agree that the check should be changed to .loaded as best practise.
The tutorial is a bit old now and I’m not keen on checking against the resource rather than the asset so I have a look at changing this now.
If one tries to render the C-letter (in ‘Asset reg.’ example), it will only work if ‘L’ for load has been pressed. As such this L-press is a deliberate keypress-action (sorry button-action was misleading). If one codes a listener, or more precisely; a function that constantly checks for ‘.loaded’ (most likely called within .update) the ‘event’ of a model suddenly becoming visible/suddenly being .loaded===true, the cause is different. I perceive/consider that as a more passive cause (non-deliberate … without a user input).
The tutorial is meant to have it as a deliberate action to show how to use the assets.load function and how to check if assets are loaded or not.
It sounds like you would like an example where a user presses a button that loads the asset and when it is ready, assign it to an entity?
Or you want an example that just does automatically when it is needed? Eg enabling an entity that has an unloaded asset and it loads it on enabling the entity.
This is sort of shown at the end of the document with the ready event.
var asset = this.app.assets.find("A");
asset.ready(function (asset) {
// do something with asset.resource
});
this.app.assets.load(asset);
This is automatic in PlayCanvas if a component (let’s say model) has an asset assigned to it that is not loaded, generally most PlayCanvas components will request the asset to be loaded and handle it when has finished loading.