So I have a large (138mb) reality file that I want to user to be able to interact with via Safari quick view.
So I have done the following:
<a
href="...link to .reality file"
rel="ar"
>
<img />
</a>
now obviously since its such a large file it takes a few minutes to download, now the apple docs are not great when it comes to the web side of reality kit so I'm wondering if there is anything I can do to improve the experience for the user?
3D models for AR and VR apps are determined by polygon count and texture size, not MB (the size in MB is important when uploading/downloading a file over the internet). Apple documentation clearly says about assets for RealityKit:
...Keep the polygon count of your 3D asset's geometry below 100,000 polygons.
So, your asset contains significantly more polygons than needed. However, models with 25K polys (or lower) will load much faster. Another important aspect is textures. Apple says about that:
...For textures, don't surpass a size of 2048 x 2048 pixels (1024 x 1024 is preferable).
You can check a polygons count for .usdz files in Attributes Inspector in Xcode.
The size of the file House.usdz is 8.4 MB.
Related
In the previous places of employment I have used
to supply #3x png assets dodging #2x,
in the new place folks use pdfs to dodge multiple assets per image semisoft(?) requirement.
My understanding is that single #3x png is still cheaper than a pdf (exported from Figma in case it matters any)
What are the pros and cons of each method
of supplying assets?
1. lazy approach: #3x.png only
2. #2x & #3x (texture interpolation is better? faster?)
3. pdf
Bonus question: it would be interesting to know if SVG is mapped into CoreGraphics/CoreAnimation and what's that cost of THAT too.
Thanks!
This is far too complex of an issue for Stack Overflow -- but to give you a couple things to think about...
If your SVG is complex - say it has 1,000 layers with various gradients and alpha values - and will only ever be displayed in your app at 300 x 200 points (that is, 600 x 400 and 900 x 600 pixels), you'd almost certainly want to render #2x and #3x pngs.
If your SVG is a simple-ish line drawing, and may be displayed at various scales and / or ratios, then SVG will give you better results.
If it takes your art department 10 hours to produce #2x and #3x png, but takes them 40 hours to produce an SVG, well?
If your image is a photograph?
If your image is a tab-bar icon?
And so on.
No idea what your app is about, but would 25% smaller storage matter? Would 50ms vs 75ms load time matter?
Best to do some research - there are many, many articles about this out there.
I have looked everywhere and at Unity iOS Build size is way big, and after building my game for iOS it is way too big at 170 MB. I checked my player size statistics in the editor log and 96% of the size is textures - this is because as I was going into this box and maxing out everything (I did not know what I was doing):
Now I need to go back and reduce my asset sizes. I don't know a lot about texture compression so I need to know - for iOS (and Android later), what are the optimal settings in this override box for compressing textures to minimum size?
Is there a way to do this to multiple images at once? What should the compressor quality be?
This is a great time to learn about the AssetPostProcessor! Specifically, AssetPostProcessor.OnPreprocessTexture will allow you to automatically handle the import settings of textures in your Unity project. It will modify their meta files as they're imported and Right-click > Reimport will force them to run (you can use this on a whole directory; even the whole Assets directory).
As far as which settings you should use, that's entirely dependent on your project. A few thoughts:
Make sure your Max Size is appropriate for the textures. Icons don't need to be 4k and background images shouldn't be scaled down to 256.
Compressor Quality "Normal" is fine in most cases. Any compression is far better than no compression.
We use "Compressed ETC2 8 bits" on Android and "Compressed PVRTC 4 bits" on iOS.
Whether or not you use "RGB" vs "RGBA" is important to consider; textures that don't need an alpha chanel would be wasting memory if you choose "RGBA" and textures that do need one wont function properly if you choose "RGB".
For my SpriteKit game I am using a single pdf vector graphics for my SKSpriteNodes rather than many png sprites for all device resolutions for every entity in the game. the benefits of not having to worry too much about the graphics of the game have dramatically helped but my question is simple, would using vector graphics be a bad idea performance wise?
Wait, you are NOT using a PDF as texture for the SKSpriteNode
Instead you are probably using a PDF into the Xcode Asset Catalog right?
In this case, first of all this is a really good idea and it does NOT impact the performance of your game.
Infact when you load a PDF image into the Xcode Assets (and you set the Scale Factors to Single Vector), you are not using the PDF into your app or game.
As soon as you compile the app, Xcode automatically generates the PNG versions for the several resolutions.
E.g. if you game does support any device running iOS 9 then Xcode
automatically generates the 1x, 2x and 3x PNG (bitmap) images from your
original PDF (vector).
Another great benefit of this approach: if in the future Apple does release a device with a 4x pixel density, Xcode will likely be updated to support that and you'll just need to recompile your app to automatically generates the 4x images.
Answer
So the answer to your question is: NO. The PDF image will not impact your game performance simply because the game is not using the PDF, it's using the PNG instead (even if you can't see it).
I'm using Unity3d (4.3.1) and NGUI for creating an 2d iOS (iPad) app. Also I need to use a lot of full screen images (about 100 images with size 2048x1536), for Gallery for example.
Now I'm using them with GUI type, override for iPhone with max size 2048 and compression quality: normal. And I'm using a UITexture with Unlit/Transparent shader to show them.
However, after about 40 images in the project XCode returns the terminated due to memory error. So the question is, what type of images do I need, and with which preferences to make them work?
I'm using iPad 3 as a test device with XCode 5.1.1. I'll be thankful for any help!
Also I need to use a lot of full screen images (about 100 images with size 2048x1536), for Gallery for example.
I think your 2048x2048 size images use a very huge memory area. Basically, 2048 image use 16MB memory. So, this case need to use about a 1600MB memory! Normal application don't over about 200 MB.
So, I think you need to be reduce using a memory:
Remember that this texture is going to be expand 2048x2048 by unity.( http://www.opengl.org/wiki/NPOT_Texture ) So, if you are going to reduce file size to 1500x1000, your application still use 2048x2048 image. But if you can reduce file size to 1024x1024, do it. 1024 image just use 4 MB memory.
If you can use texture compression. Use it. PVRTC 4 bit ( https://docs.unity3d.com/Documentation/Manual/ReducingFilesize.html ) compression is make file size 1/8 than true color. Also memory size is going to reduce.(maybe reduced to half)
If your application don't display all images, load image dynamically. Use thumb nail.
Good luck:D
If you want to make a gallery-like app to render photos maybe you can try a different approach:
create two large editable textures and fill texels with image data (it must be editable otherwise you will no have access to write directly image data into them).
if you still have memory issues or if you want to use lower memory you can use several smaller textures as tiles. You can render then image parts to each smaller texture. Remember to configurate correctly the texture borders or so not use border texels to avoid wrapping problems.
Best way is to use a smaller texture. In an ipad you will need a magnifying glass to really appreciate the difference between 1024x1024 and larger textures. Remember an ipad screen is smaller (7"~10") than a computer one and with filtering enabled is really hard to tell the difference.
If you still need manager such a large texture for some other reason (zooming or similar) I recommend you one of the following approaches:
split the texture into layers with alpha channel (transparency): usually backgrounds can be rendered with lower resolutions.
split also the texture into blocks: usually most textures have repeating patterns.
use compression.
Always avoid use such large textures if possible.
I want to display a page containing about 6000 tiny image thumbnails (40x40 each). To avoid having to make 6000 HTTP requests, I am exploring CSS sprites, i.e. concatenating all these thumbnails into one long strip and using CSS to crop the required images out. Unfortunately, I have discovered that JPEG files cannot be larger than 65500 pixels in any one dimension. Wary of further limits in the web stack, I am wondering: are any of the following unable to cope with an image with dimensions of 40x240000?
Internet Explorer
Opera
WebKit
Any CSS spec
Any HTML spec
The PNG spec
Edit: the purpose of this is simply to display an entire image collection at once, requiring that the user at most has to scroll. I want the "micro-thumbnails" to flow into an existing CSS layout, so I can't just use a big rectangular image. I don't want the user to have to click through multiple pages to see everything. The total number of pixels is not that great - only twice what would fit on a 2560x1600 display. The total file size of all the micro-thumbnails is only a couple of megabytes. Assuming every image is manipulated uncompressed in the browser's memory, taking 8 bytes of storage per pixel (RGBA plus 100% overhead fudge factor), we are talking RAM usage in the low hundreds of megabytes; not unreasonable for a specialized application in the year 2010. The only unreasonable thing is the volume of HTTP requests that would be generated if all micro-thumbnails were sent individually.
Well, Safari/iOS lists these limits:
The maximum size for decoded GIF, PNG, and TIFF images is 3 megapixels.
That is, ensure that width * height ≤ 3 * 1024 * 1024. Note that the decoded size is far larger than the encoded size of an image.
The maximum decoded image size for JPEG is 32 megapixels using subsampling.
JPEG images can be up to 32 megapixels due to subsampling, which allows JPEG images to decode to a size that has one sixteenth the number of pixels. JPEG images larger than 2 megapixels are subsampled—that is, decoded to a reduced size. JPEG subsampling allows the user to view images from the latest digital cameras.
Individual resource files must be less than 10 MB.
This limit applies to HTML, CSS, JavaScript, or nonstreamed media.
http://developer.apple.com/library/safari/#documentation/AppleApplications/Reference/SafariWebContent/CreatingContentforSafarioniPhone/CreatingContentforSafarioniPhone.html
Based on your update, I'd still really recommend not using this approach. Don't you think there's a reason that Google's image search doesn't work like this?
As such, I'd recommend simply loading images as required via Ajax. (i.e.: When the user scrolls below the currently visible set of images.) Whilst this will use more connections, it'll mean that you can have sensibly sized thumbnails and as a general approach is much more manageable than having to re-generate pre-generated thumbnail image "sheets" on the back-end when a new image is added, etc.