I always love seeing Godot posts here, gets me inspired! I put together a quick gallery demo project that resolves a lot of the issues you're dealing with. Obviously this is just a simple demo...
I always love seeing Godot posts here, gets me inspired!
I put together a quick gallery demo project that resolves a lot of the issues you're dealing with. Obviously this is just a simple demo project and could use better lighting, textures, models, etc. I just grabbed some stock images to use as "art" in the gallery.
I'm using the "Quality First Person Controller v2" for FPS controls. I had to tweak the code a little bit to get mouse capture working correctly (as you found out, mouse capture doesn't work the same for a web export as it does in the Godot editor).
i've been dabbling for a while but so far all of the things i use the webexport for are 2d things that dont need mouse capture stuff and it was fine the one time i did it by mistake is there...
mouse capture doesn't work the same for a web export as it does in the Godot editor
i've been dabbling for a while but so far all of the things i use the webexport for are 2d things that dont need mouse capture stuff and it was fine the one time i did it by mistake
is there anything specific that breaks it? im always just capturing it on click and revealing it on ESC or the menu layer
Yep, capturing it on click or from some other input seems to be the preferred way. Here's the godot docs source that highlights the differences for web export...
Yep, capturing it on click or from some other input seems to be the preferred way.
The reason why it was broken in 3D is that the add-on FPS controller code (depending on which one you use) sets the capture mode in _ready and that works in the editor, but not in the web export. I moved that to _unhandled_input and set it to captured if the mouse is clicked.
Ok, so. I'm trying to build a walk-through gallery for my art in Godot, link is where we're at so far. This is my first such project, and I'm very much still stumbling my way through, so please...
Ok, so. I'm trying to build a walk-through gallery for my art in Godot, link is where we're at so far. This is my first such project, and I'm very much still stumbling my way through, so please assume you're addressing any suggestions to a moron lol.
The Issues (roughly in order of importance):
-mouse capture(?): I think this is the term here, for using mouse movements to move the camera. It works fine in the editor, and it looks like (part of?) the code is there for it, but clearly something is missing. The player aspect was a prefab thing from the asset library, I did not code it myself. (With the player I'd also like to be able to handle stairs w/o jumping, but that's less important right now)
-black boxes: you can (hopefully) see the one jpeg that's loading correctly, and all those other black squares are supposed to be like that. It seems like this might be a known issue, with one suggestion being to resize to a multiple of 4.... Problem is 1) what/where exactly am I resizing, because I'm only seeing a scale transform option (and I assume we're taking pixels?), and 2) I tried resizing one that way (scale transform) to be the same as its neighbor (which was showing correctly) and now neither show.
-load time: it takes so long to load, and I feel like there must be something I'm doing wrong there, but I have no idea what I can cut out/change/do differently to make the whole thing less bloated.
-mobile controls: I haven't looked too much into this one yet, but might as well throw it in while we're at it.
Those are my current pain points, explained to the best of my ability. Happy to clarify if necessary, and just because I said I tried something doesn't mean I tried it correctly; no offense will be taken if we need to start with a "turning it off and on again" equivalent.
(Idk where to put this, or how to tag it, so mods feel free to move/change as desired)
Your asset bundle aMAZEing.pck is 202MiB. That's a lot. Try tweaking compression on the imported materials. Since I am on a train / mobile data, it didn't even load for me. As for the rest, I...
Your asset bundle aMAZEing.pck is 202MiB. That's a lot. Try tweaking compression on the imported materials. Since I am on a train / mobile data, it didn't even load for me.
As for the rest, I don't understand what you are asking us to do. Are you trying to recruit people to help you make the game? Are you looking for someone to mentor you?
Lol you should've seen it when they were PNGs! I'm not looking for someone to do it for me, I just need a little guidance. I had no coding experience before this, so while I've read through pages...
Your asset bundle aMAZEing.pck is 202MiB. That's a lot.
Lol you should've seen it when they were PNGs!
I'm not looking for someone to do it for me, I just need a little guidance. I had no coding experience before this, so while I've read through pages like the one you linked (many times) I'm still struggling to internalize what's being said. So like, do you have a recommendation for which file type I should be using for the art images? I know there are tradeoffs for each, but where's the happy medium between image quality and size?
I don't believe the one-big-bundle approach will work well for an online experience in the first place. I would use at most 1024x1024 assets with heavy JPEG compression and added blur to combat...
I don't believe the one-big-bundle approach will work well for an online experience in the first place. I would use at most 1024x1024 assets with heavy JPEG compression and added blur to combat the artifacts and when user gets real close fetch full quality image on the fly. You are not the first person looking into this, though.
I would also disable precomputed mipmaps and somehow prepare them on the client. If necessary for whatever pixel density / client resolution you expect.
I think most people will leave the page quickly a won't explore that much. They shouldn't download all of it beforehand. Just enough to decide whether they wish to keep exploring. Plus your hosting/housing might not be happy about those huge transfers. They pay for outgoing data after all.
JPEG isn't a bad choice, one thing you may want to try is tweaking the compression. Depending on which image editor you're using there might be good options in the save/export process....
JPEG isn't a bad choice, one thing you may want to try is tweaking the compression. Depending on which image editor you're using there might be good options in the save/export process.
Alternatively you could try an app dedicated to lowering image file sizes. To give you an example of what that looks like, put one of your images through an online image shrinker like: Tiny JPG
At the end of the day, though, the file size on a package of photo quality images is always going to be pretty big. It's going to feel clunky having to load everything in advance, an in Godot, no matter how much compression you do.
One option might be to trim it down to a smaller selection of only your best work and then link out to a more traditional website for the rest.
If you have no coding experience, I’d suggest godot is probably not the best thing to start with. Some design choices are a little non standard, but more importantly there are not many tutorials....
If you have no coding experience, I’d suggest godot is probably not the best thing to start with. Some design choices are a little non standard, but more importantly there are not many tutorials. I have some amateur coding experience (python, web, basic C etc) and find the lack of godot 4 tutorials makes it much harder.
Can I suggest you start with a python course? There are modules that allow for game making within python, and godot script is based on python too. There are a huge number of courses and tutorials for python (and it’s very beginner friendly), so that will kickstart your coding skills.
I always love seeing Godot posts here, gets me inspired!
I put together a quick gallery demo project that resolves a lot of the issues you're dealing with. Obviously this is just a simple demo project and could use better lighting, textures, models, etc. I just grabbed some stock images to use as "art" in the gallery.
I'm using the "Quality First Person Controller v2" for FPS controls. I had to tweak the code a little bit to get mouse capture working correctly (as you found out, mouse capture doesn't work the same for a web export as it does in the Godot editor).
Demo here: https://gallery.tomsdocs.com/
Project code here: https://github.com/paolonit/art-gallery
If you want, you can pull down that project code and use it. If you have questions about anything, feel free to ask!
Oh my god, you're amazing! I can't wait to poke at this, thank you!!
i've been dabbling for a while but so far all of the things i use the webexport for are 2d things that dont need mouse capture stuff and it was fine the one time i did it by mistake
is there anything specific that breaks it? im always just capturing it on click and revealing it on ESC or the menu layer
Yep, capturing it on click or from some other input seems to be the preferred way.
Here's the godot docs source that highlights the differences for web export https://docs.godotengine.org/en/4.4/tutorials/export/exporting_for_web.html#full-screen-and-mouse-capture
The reason why it was broken in 3D is that the add-on FPS controller code (depending on which one you use) sets the capture mode in _ready and that works in the editor, but not in the web export. I moved that to _unhandled_input and set it to captured if the mouse is clicked.
Ok, so. I'm trying to build a walk-through gallery for my art in Godot, link is where we're at so far. This is my first such project, and I'm very much still stumbling my way through, so please assume you're addressing any suggestions to a moron lol.
The Issues (roughly in order of importance):
-mouse capture(?): I think this is the term here, for using mouse movements to move the camera. It works fine in the editor, and it looks like (part of?) the code is there for it, but clearly something is missing. The player aspect was a prefab thing from the asset library, I did not code it myself. (With the player I'd also like to be able to handle stairs w/o jumping, but that's less important right now)
-black boxes: you can (hopefully) see the one jpeg that's loading correctly, and all those other black squares are supposed to be like that. It seems like this might be a known issue, with one suggestion being to resize to a multiple of 4.... Problem is 1) what/where exactly am I resizing, because I'm only seeing a scale transform option (and I assume we're taking pixels?), and 2) I tried resizing one that way (scale transform) to be the same as its neighbor (which was showing correctly) and now neither show.
-load time: it takes so long to load, and I feel like there must be something I'm doing wrong there, but I have no idea what I can cut out/change/do differently to make the whole thing less bloated.
-mobile controls: I haven't looked too much into this one yet, but might as well throw it in while we're at it.
Those are my current pain points, explained to the best of my ability. Happy to clarify if necessary, and just because I said I tried something doesn't mean I tried it correctly; no offense will be taken if we need to start with a "turning it off and on again" equivalent.
(Idk where to put this, or how to tag it, so mods feel free to move/change as desired)
Thanks!
Your asset bundle
aMAZEing.pck
is 202MiB. That's a lot. Try tweaking compression on the imported materials. Since I am on a train / mobile data, it didn't even load for me.As for the rest, I don't understand what you are asking us to do. Are you trying to recruit people to help you make the game? Are you looking for someone to mentor you?
Lol you should've seen it when they were PNGs!
I'm not looking for someone to do it for me, I just need a little guidance. I had no coding experience before this, so while I've read through pages like the one you linked (many times) I'm still struggling to internalize what's being said. So like, do you have a recommendation for which file type I should be using for the art images? I know there are tradeoffs for each, but where's the happy medium between image quality and size?
I don't believe the one-big-bundle approach will work well for an online experience in the first place. I would use at most 1024x1024 assets with heavy JPEG compression and added blur to combat the artifacts and when user gets real close fetch full quality image on the fly. You are not the first person looking into this, though.
I would also disable precomputed mipmaps and somehow prepare them on the client. If necessary for whatever pixel density / client resolution you expect.
I think most people will leave the page quickly a won't explore that much. They shouldn't download all of it beforehand. Just enough to decide whether they wish to keep exploring. Plus your hosting/housing might not be happy about those huge transfers. They pay for outgoing data after all.
JPEG isn't a bad choice, one thing you may want to try is tweaking the compression. Depending on which image editor you're using there might be good options in the save/export process.
Alternatively you could try an app dedicated to lowering image file sizes. To give you an example of what that looks like, put one of your images through an online image shrinker like: Tiny JPG
At the end of the day, though, the file size on a package of photo quality images is always going to be pretty big. It's going to feel clunky having to load everything in advance, an in Godot, no matter how much compression you do.
One option might be to trim it down to a smaller selection of only your best work and then link out to a more traditional website for the rest.
Cool, I'll look into that, thanks!
If you have no coding experience, I’d suggest godot is probably not the best thing to start with. Some design choices are a little non standard, but more importantly there are not many tutorials. I have some amateur coding experience (python, web, basic C etc) and find the lack of godot 4 tutorials makes it much harder.
Can I suggest you start with a python course? There are modules that allow for game making within python, and godot script is based on python too. There are a huge number of courses and tutorials for python (and it’s very beginner friendly), so that will kickstart your coding skills.