OpenVGal / 3D web galleries created programmatically (Help welcome !)

artwork images should be external , not the actual geometry of the frame or canvas, i mean the 2d texture sources.

Images/videos are the largest assets normally in any web app technology. The loading is important because you can get things onto screen faster. Stage loading ( getting stuff on screen faster ) reduces the actual experience of waiting to end users. Developers have been working on better UX practices like this for decades by now , even in HTML , there are ways of making a page less “blocking” ( getting stuff on screen faster ) by using deferred loading and moving script tags into the end of the body instead of the head etc.

Its good practice and probably better to make such a design choice up front in the early stages since its basically common practice. You might not be creating a regular website , but you still creating something to be consumed by web technologies and the same UX concepts still apply in regards to loading times.

1 Like

Hi guys,
Thanks for your feedback once again. I have been away some weeks due to force-majeure issues. Now I am back with the first update (v0.2). I realized that the large glb files were going to be an issue for many websites. The new version works with a versitile approach:

  • If the glb files are found in the server, it works as before
  • If the glb files are not found it will try to re-create the halls on the fly

This variant reduces a lot the amount the amount of downloaded information (from 50 MB to 5 aprox) and the rendering time is good enough. Here is an example:

This update is an intermediate step for a hybrid rendering where the glb file has everything but the artworks. It would have placeholders that can be filled in on-the-fly with images from a folder. The glb file can have the nice design and baked textures and yet the gallery can update very easily the content.

Keep you posted. Again, help is welcome.

1 Like

I’m not sure to understand how you can get 50mb of meshes from just a few walls. Not to mention that they can be for a part instanciated.

Artworks should not be part of the structural file anyways. Here again, the frame(s) should be a separate file or object and again can also be instanciated if they are of a same size or ratio. The artwork itself being projected on a plane parented to the frame and if everything is fully dynamic, the frame can use the 9-patch shader created by PatrickRyan to project a simple shadow on the wall.
(while the shadow from all structure would be baked in the glb of structure only). And then the artworks (pictures) for each hall can also be part of a container loaded only when accessing this hall.

Of course my approach and opinion only.

Well, it is probably an unefficient way to do it. It is coming from the wall material.

Thanks for the suggestions and Patricks proposal. I dont know what exactly you mean by this quote. Container loading happens only when the halls are accessed. The first time are loaded from the server and in subsequent visits the container remains in memory.

1 Like

From my point of view, I agree with @mawa in a question of optimization, 5 mb is too much at least for a model as simple as the one that can be seen in the demo, of course for the wall models you should avoid using materials complex with textures and simplify it to the maximum.

Optimization is key to the success of the application and you will have to analyze very carefully each asset that you are going to use in the project, that point is one of my great obsessions.

In any case, I propose the idea of using different dimensions for the images and gradually adapting the resolution depending on the proximity of the object.

Another option would be to work with textures at lower resolution and integrate a frame detail viewer by clicking on it to show the image in high quality, especially on mobile devices.

Consider that mobile internet traffic is more than 80% and on the mobile device screen is always necessary to analyze the user experience well. Using viewers and overlays is usually a more viable option to develop a good UX strategy.

This is a simply personal appreciation, without a doubt I encourage you to develop such an interesting project and to have success :smile:

Oh sry, I didn’t check it, to be honest. So this part is already done :smiley: GJ there,

We are talking 50mb and not 5mb from what I did read. Might be an error though. In any case, you are right: 5mb would already be a lot for the mesh(es) and wall material(s). If this is the case, some heavy optimization can/should occur there.
I mean I’m building my entire space museum with 500 meshes and 50 materials and then, in heavy .obj format, and I have much less than 50mb altogether while featuring a huge space of fancy capsule shape with 5 elevators, a restaurant with a capacity of 70, 2 docking hubs, 15 toilet cabinets, 3 showers, 24 lockers and a lot more. All with less than 20mb of meshes import and less than 30mb of textures.
The materials for walls need to be tiled. Each wall or ground material in PBR should likely not exceed 1-1.5 mb assuming it has i.e. a base + a normal + a roughness + eventually one more. The point is you likely want to keep max resources to display all works of art in best quality.

1 Like

Let’s see if we’re lucky and bjs6 has an automatic asset optimization system managed by an AI :joy:

1 Like

Hi everybody !
After a few months hiatus where I was busy developing the part in blender I have posted in github a new version (a demo is also available here: LB Artworks) of the software that deals with three levels of complexity:

  • full pre-built glb
  • glb with architectural elements and on-the-fly loading of the artwork (Antarctica gallery)
  • complete on-the-fly construction of the hall

I have some blender python code to automatically generate the hall based on the same json file as used with Babylon.JS. Still the baking of the textures and UV unwrapping is not automatic (Im working on it)

These three options give better performance and flexibilty. However, use is probably now at the highest point of complexity for an artist. Next steps in the TODO list should be aimed to lower that bar and improve the code design. As always if any of you want to improve any part of the code, you are welcome !! :heart: