Archviz to HTML5? or it's real to package large project?

[6r0m]

I have project over 4 Gb. May be I could optimize it to 1Gb. I understand too about other restriction (light, materials) for mobile.
But I read that even 500 Gb is very big for webgl.

For now after packaging I have 1.18 Gb (before 4 Gb) and a lot of memory errors (on different browsers, 64bit too).

HTML 5 and large project it’s possible?

[anonymous_user_d9aa7bc0]

bump, I wanna know too

[anonymous_user_a08c0bf2]

6r0m,

Please review our [documentation][1] as it has quite a bit of suggestions on [packaging projects][2], [mobile game development][3], [performance guidelines][4] and [package blacklisting][5].

Thanks!

Unreal Engine 5.1 Documentation | Unreal Engine 5.1 Documentation
[2]: Packaging Unreal Engine Projects | Unreal Engine 5.1 Documentation
[3]: General Mobile Development for Unreal Engine | Unreal Engine 5.1 Documentation
[4]: Performance Guidelines for Mobile Devices in Unreal Engine | Unreal Engine 5.1 Documentation
[5]: Optimization Guides for Android in Unreal Engine | Unreal Engine 5.1 Documentation

[6r0m]

, are you robot?) I observe - if you answer, the problem is not solved(

[anonymous_user_a08c0bf2]

Depending on the size of your project, it may be too large for HTML5. However, the documentation that I provided should’ve had enough information to help size down your project. Because when you’re packaging for HTML5, you’d want to focus on following the guidelines for mobile development because HTML5 is more similar to mobile than Windows (for instance).

If you’ve already went through all of the documentation, blacklisted and changed your textures, etc as much as you’re possibly able to - - you’re going to need to provide a bit more information for me to further assist you.

Thanks!

[6r0m]

, thanks for you time, but it some not helpful, I try to explain - when epic staff usually answering - he give it accurate and add that if you now more about it see there (give an additional links).

But you don’t know answer but give a link to information, many links with different information. again and again. Thank you but I can use with same result.

And if you want to make your supporters more little happy - try to understand questions, please. My question fairly accurate above. And answer for it - “No, you can’t use this size, because maximum size for webgl browser 32 bit is xxx”

now answers like this seems like epic try to make visibility that it have good technical support.

thank you too.

anyway - I tried to do it by null and some happen House by 6r0m
there are many issues with resolution, canvas. normal movement. They can be resolve with additional knowledge in java.
I understand now that html5 epics has no support, but ok, I can live without it if your guys make good support for your things in trend (VR for ex.)

[anonymous_user_7e4e2181]

it would behoove you to try to keep the download size as small as possible for web users. smaller download times make happier web users.

that said, work is being done by the makers of emscripten to help make better use of downloaded assets (asynchronous file fetch and store - faster “future” page revisits) as well as improve performance via web assembly. these are targeted for 4.16.

• size of assets supported is hardware dependent. so use your best judgement on who your target users are.

as to the errors you’ve mentioned.

• the framebuffer clear and framebufferTexture2D is something on my backlog that started when webgl standards continue to improve and needs to be addressed.

i tried your latest on my browser and it seems to work pretty well. movement direction works fine. the change object and color also works fine.

• your question about the canvas and resolution is open ended… what about them?

finally, java is not javascript.

hope this helps!

[6r0m]

thank you for your attention!

1. about resolution and canvas - 1.1) In Editor not work or anti-aliasing or resolution not set by default with my specs. After packaging it’s the same - edges are not smoothly. But there is more problem 1.2) after playing full screen “not work” - canvas full screen but game inside no (it’s the same size with black around it)

I reviewed about it:
"The width: 100% CSS directive is what caused the visible presentation size of the canvas to scale up to fit the browser window. The CSS directives don’t affect the WebGL render target sizes, so the engine can still continue to render to its existing sizes independent of what the visible presentation size is. It would be possible to register a resize handler in JavaScript land to resize the WebGL canvas when browser window is resized, if one wants to match the visible size to the WebGL render target size. "

It’s from here https://answers.unrealengine.com/questions/416601/really-low-screen-resolution-in-initial-launch-of.html

I don’t understand how to use java script unfortunately(

2) it’s small but little sad - to disable mouse cursor for normal game mode movement I don’t understand yet a combination keys for it. I trying different and some it work and some no.

About this issues I tried to found documentation but on the official there is one small page about html5 . I found similar (forum, answerhub) but answers seems that need to work with the help of crutches and more specific knowledges.

[anonymous_user_7e4e2181]

1.1) edit DefaultEngine.ini – and under [SystemSettings], double check the r.setRes setting to see if it’s set with your specs. it should look something like:

r.setRes=WidthxHeight

for example:

r.setRes=800x600

do note: this is the “game resolution” – what the engine uses – the canvas resolution is different (to be addressed below in 1.2)

1.2) what version is your browser? i just tried it on mine (firefox 50.1.0 on my OSX laptop) and your project runs full screen and back fine.

that said, i do know there is currently a problem with “black borders” around the top and right side of the canvas every now and then (very visible when you just adjust the width and height of your browser). i already have a task on that (UE-36341 & UE-32311) and am working on it presently.

2. mouse control “take over” is easy to trigger on your scene - (again, i’m testing on firefox on OSX) move the mouse out of your game canvas and then back in – on the next click, the browser will try to “lock it” (i.e. “hide it”).

i know you shouldn’t have to move the mouse off canvas all the time to “fix this” – but i do have a on this (UE-35292) to clean up the mouse capture handler. not sure when i’ll get to that. i’ve got some big features to work before i get to that.

[6r0m]

1.1)

Do you use 4.14 ? I try files above - there are no r.setRes and system settings

1.2) Chrome 55.0.2883.87 m (64-bit) (Chrome - 55.83 % browser’s segment by netmarketshare)
can not work in fullscreen

Microsoft Edge 38.14393.0.0
infinitely compiling

Firefox 50.1.0
can not compiling

2. very interesting)) thank you, I should to instruct users about this, because it’s not intuitive for simple people,

[anonymous_user_7e4e2181]

hello 6r0m,

i’ve double checked the browsers with your website – and they all compile to completion and run. i have noted the browser versions (and they are all 64-bits - NOTE: i have to use chrome canary for 64 bit tests, i keep the “older” 32-bit version for testing purposes).

as for the “full screen - black border” issue – these are being tracked (as noted in my previous comment above) in UE-36341 & UE-32311. i anticipate the fix going in for 4.16 (4.15 is already on lock down).

final note: i see that the Edge browser is blowing out the lighting – these types of issues will be fixed by the respective browser makers. we will try to addressed them on our end if possible, otherwise - just wait for the next versions to come out and make a note of them in your release notes.

[6r0m]

thank you, nick

[anonymous_user_f0fea7ad]

The black borders resizing issues have known fixes, those should hopefully reach the next stable UE4 version release. You can check out the fix in action in a new WebAssembly spec demo here (needs Firefox 52 or ):

https://mzl.la/webassemblydemo

For background info, see

Why WebAssembly is a game changer for the web — and a source of pride for...

As for project code sizes, the size of the compressed .data package gives an insight to how feasible large projects are. There are fixes and improvements to UE4 memory usage that will hopefully land in next UE4 version release, which you can see in the demo page above. Currently we recommend deploying projects that have .data files <= 200 MBytes, though sizes larger than that are possible, although they will amount to larger download times at startup.

Current UE 4.15 provided main HTML page does not implement asset caching in IndexedDB, but hopefully in UE 4.16 IndexedDB storage should be enabled by default. That means that pages will store the assets to IndexedDB on first page visit, and on subsequent runs the assets are directly pulled from local IndexedDB storage without even pinging the remote server for the data.

There are two hard restrictions if the .data file gets too large:

1. The theoretical maximum size for .data file is 2GBytes. If the data size is larger than that, it cannot be loaded in web browsers.
2. Even before reaching the 2GB limit, there are different browser specific limits on how much assets can be stored to the IndexedDB API. At the moment storing 512MB is stretching it a bit, although it might work. Storing anything more than that is not feasible at present, although we are working on improving the web asset storage specifications to improve the limits in the future. If one attempts to store too much, web page consoles will print out “QuotaExceededError” or something like that to signal that the browser refused to store that much to the 's hard disk. The exact amount of quota varies by how much hard disk space one has available, for example.

In the future we expect that there will be games portals that want to implement “Steam, but on the web” types of services. That could mean multi-gigabyte downloads of games up front, so it is likely that browser will implement higher quota limits in the future to accommodate for these types of sites.