Thanks a lot for helping me optimize this! I know 16 mb sound like a lot, but for now, this webapplication will be downloaded an run locally on for example an ipad, so the downloading of the content only has to happen once and then it will load quite quickly. But anyhow, it’s interesting to see how I can I optimize it since public web might be of interest further ahead.
Good find, I did this a 1024 JPG instead. But I was under the impression that it wouldn’t matter much if the images came in PNG or JPG flavour because they’ll be converted to raw uncompressed image data anyhow, and only the compression options in the editor can help with that?
I’m using the information hotspots tutorial from @steven (Information hotspots - PLAYCANVAS) and it uses the shapepicker script which does a raycast. I was under the impression that it need the phyics engine? If it doesn’t I’ll be glad to remove that.
ShapePicker.prototype.doRayCast = function (screenPosition) {
// Get the start point of a 3D ray fired from a screen position
this.cameraEntity.camera.screenToWorld(screenPosition.x, screenPosition.y, this.cameraEntity.camera.nearClip, this.ray.origin);
// Work out the direction of the ray from the a screen position
this.cameraEntity.camera.screenToWorld(screenPosition.x, screenPosition.y, this.cameraEntity.camera.farClip, this.ray.direction);
this.ray.direction.sub(this.ray.origin);
// Test the ray against all the objects registered to this picker
for (var i = 0; i < this.pickableShapes.length; ++i) {
var pickableShape = this.pickableShapes[i];
var result = pickableShape.intersectRay(this.ray);
if (result) {
// We have hit something
var hitObject = this.pickableEntities[i];
hitObject.fire("shapepicker:hit");
}
}
};
Interesting, but even on native - size matters. People tend to not download larger apps.
And generally experience increases if waiting times are low.
So PNG - is lossless format, and it have to store pixels as they are, making files actually very large. JPG is lossy, and will introduce block pattern, but saves a lot in terms of data, and can compress in many cases better than even DXT.
When you use compressed textures, they are better to be created from PNG, but texture compression does not have 100% coverage of all platforms, and there will be platforms that have no support of any of provided, and they will automatically load original file (PNG/JPG). As well as published app does includes them, so means project does gets bigger.
And with compression, I can’t see you’ve compressed anything yet, perhaps you planning to do it as last stage of optimisations?
Glad to say, that uses analytical picking using pc.BoundingSphere and pc.Ray, so no physics involved
Great, so you’re saying if I compress in the app using the checkboxes next to DXT, PVR and ETC1 it’s better if the original is an uncompressed PNG. But if compression is not used because of the platform limitation, then I would actually be better off having a JPG from the start?
Strange, I was under the impression I had compressed most of my textures used in the materials of the 3D model. This is what they all look like in the editor:
Weird, indeed.
But there is a trick So if you upload lets say TGA without alpha, it wont be runtime format, so it will generate another asset: if no Alpha available it will make JPEG. There will be link between those assets. Then if you going to compress that JPEG, it will know that it came originally from TGA, and compression pipeline job will use TGA instead of JPEG, that way it does not inherits lossy block compression regression of JPEG. Because TGA is lossless.
So you have JPEG, and compressed textures generated out of lossleess.
Maybe I’ve tested it slightly before you’ve done it. As now I can see that texture is not loaded anymore.
Bear in mind, large textures consume way more VRAM, and mobile phones are very limited on it, so for mobile, 4K and 2K textures - shall be very very rare occasion.
