royibernthal Posted September 3, 2016 Share Posted September 3, 2016 I have 2 questions regarding loading meshes from a .babylon file: 1) I'm loading the .babylon file through the AssetsManager. Textures related to the meshes that are specified in that file are being loaded as well. Are these textures loaded right away or are they loaded only once the mesh is created? I'm preloading all assets and displaying a loading bar before the game is shown. I'd like to know if these textures will be loaded with all assets in the preloading time, or am I to expect extra loading time of these textures after preloading is over? 2) File names including paths of textures related to meshes must be specified in their designated "name" parameter in the .babylon file. It makes sense. I'd like however to create a folder per .babylon file, with the .babylon file and all its textures in that folder. Therefore, I'd like the textures specified in the babylon files to only include the name of the texture file, and adjust the path prefix at runtime according to the .babylon file path. For example, let's say I have the babylon file assets/meshes/meshName/data.babylon, and a texture specified in it is located in assets/meshes/meshName/. I'd like to specify in the texture's name parameter only "textureName.png" instead of "assets/meshes/meshName/textureName.png" and to add the path prefix "assets/meshes/meshName/" which will be derived from the path of the .babylon file at runtime. Is that possible? How should I approach this problem? I'd like to avoid having to manually edit paths in every .babylon file since I'm likely to be facing hundreds of those. I can also think of a dozen ways to modify the .babylon file's actual content before it is even loaded, but I'd like to avoid these as well for the sake of a "prettier solution to the problem". fluffrabbit 1 Quote Link to comment Share on other sites More sharing options...
jellix Posted September 4, 2016 Share Posted September 4, 2016 Hi @royibernthal, question1: Don't know for 100% but pretty sure that the AssetLoader also loads the textures of babylon-files before it dispatches the load-complete event. question2: Don't understand exactly. It shouldn't be a problem to add an order-path to a filename of a texture dynamically AFTER the babylon file is loaded (could explain it if u want). But I think that the problem would be that the AssetManager throws errors while loading because it tries to load the textures (and doesn't find it) before you give the correct filepath to the loader. Quote Link to comment Share on other sites More sharing options...
royibernthal Posted September 4, 2016 Author Share Posted September 4, 2016 9 minutes ago, jellix said: question2: Don't understand exactly. It shouldn't be a problem to add an order-path to a filename of a texture dynamically AFTER the babylon file is loaded (could explain it if u want). But I think that the problem would be that the AssetManager throws errors while loading because it tries to load the textures (and doesn't find it) before you give the correct filepath to the loader. That's the whole point To change the textures' paths before the AssetsManager attempts to load the them. Quote Link to comment Share on other sites More sharing options...
jellix Posted September 4, 2016 Share Posted September 4, 2016 Oh I see ... sorry no solution from me :-( The best would be to load the files without materials but I don't think that it's possible with babylon files. With obj files it is just by ignoring the corresponding mtl-file. And it's no solution to keep all textures in one summary folder? And if the AssetManager doesn't find the texture, does it stop? Or does it just throw an error and goes on? If so, maybe it would be a solution just to ignore the missing textures and to apply them afterwards. Quote Link to comment Share on other sites More sharing options...
royibernthal Posted September 4, 2016 Author Share Posted September 4, 2016 It'll result in the extra overhead of the failed requests, it won't be a "clean solution" due to that and a couple of other reasons Quote Link to comment Share on other sites More sharing options...
royibernthal Posted September 5, 2016 Author Share Posted September 5, 2016 @Wingnut webGLmmk and Wingnut 2 Quote Link to comment Share on other sites More sharing options...
royibernthal Posted September 19, 2016 Author Share Posted September 19, 2016 Anyone? Quote Link to comment Share on other sites More sharing options...
GameMonetize Posted September 20, 2016 Share Posted September 20, 2016 So 1. Yes this is how the AssetsManager works so you're fine 2. Depending on which exporter you are using, it should already be the case. babylon files should only contains relative side by side texture filenames Quote Link to comment Share on other sites More sharing options...
royibernthal Posted September 20, 2016 Author Share Posted September 20, 2016 Here's a PG demonstrating that textures are not loaded when specifying relative paths in the .babylon file: http://www.babylonjs-playground.com/#1SVN3I#4 Here's the .babylon file: http://runeslots.com/misc/bulbasaur_relative/data.babylon For instance, this doesn't work: "diffuseTexture":{"name":"pm0001_00_BodyA1.png" It attempts to load: http://www.babylonjs-playground.com/pm0001_00_BodyA1.png I'd like it to load: http://runeslots.com/misc/bulbasaur_relative/pm0001_00_BodyA1.png Based on the file path of the .babylon file. Quote Link to comment Share on other sites More sharing options...
GameMonetize Posted September 21, 2016 Share Posted September 21, 2016 It works when you specify scene root: http://www.babylonjs-playground.com/#1SVN3I#5 royibernthal 1 Quote Link to comment Share on other sites More sharing options...
royibernthal Posted September 21, 2016 Author Share Posted September 21, 2016 Oh I understand, thanks. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.