While working on Morterra, I’ve come across a few things that I have questions about:
While rendering ground items, I’m currently just creating an instance of a plane with the item, and using billboard mode to display the item on the ground. I was looking into using Sprites (Sprites - Babylon.js Documentation) - one main reason is that I would like to reduce my load time (currently loading the item images individually, but I have a spritesheet ready to plug in) & Sprites make it easy to use the spritesheet. BUT the only problem I have with the Sprites is that there is no way that I have found to multipick sprites… I currently have it so players can see a list of stacked items if there are multiple items in the same position. I noticed the multipick methods return pickedSprites, but it always returns undefined… and there is a separate method for pickSprites, which works but only returns a single Sprite. Question: Is there a way to multipick sprites? If not, is there an easy way to implement a spritesheet to my current method (drawing image to a plane in billboard)?
Instanced objects sometimes have submeshes disappear when looking at them at the right angles. I have tried setting the mesh as always active, as I have seen in many other user’s posts, and that seems to only make the problem happen a little less. Cloning them works fine and never has the disappearing problem, but it would be more efficient to use instances. I’m wondering if there are any common reasons this would happen?
Morterra uses a zoning system so that players only render in zones close to them (the map will be huge in the future, so this feature is necessary). While crossing zones, there is a bit of a delay because the object models for the next zones are being loaded in at real-time. This causes a noticeable freeze in frames if there are enough models being loaded in. I’m considering writing a queue system to only load in the new object model if the client has the time/resources to load it (within reason). This would spread out the new models loading, so each frame would drop a few FPS, rather than a few frames going to 0. Is there anything remotely similar to this that I could look into, or are there any other things I should consider that may help reduce load times in general?
@morterra sorry for your delay in getting an answer, your question seems to have disappeared down the stack of questions. Even if my answers don’t exactly solve your problems at least it will get bumped.
Cannot help with multipick never looked at it or used it. I will have a look once my current project is finished. Here is one way to add a sprite from a spritesheet to a plane. Note plane must be updatable. How easy it is is up to you https://www.babylonjs-playground.com/#9RI8CG#89
can you reproduce this? share a screen recording? playground would be the best.
How large are your objects? this happens only when you load a huge object and the engine needs some time to deal with the vertex data. Will it be possible to break it down to different meshes? or maybe anticipate the user’s action (if possible) and trigger a load prior to the time it is needed?
I appreciate the feedback you guys. This will help point me in the right direction.
@JohnK Your solution for #1 seems like it should work fine, I was hoping there was some native behavior with Sprites I was missing. For #3, that thread seems to have some of the info I was looking for, but again I guess I was hoping there was a native async loading for chunking. These should work though! Thank you for the help!
@adam That seems like that may just be the issue, I haven’t tried messing with the bounding box, since they are instanced meshes. I’ll try this out and get back to you. Thanks for the help!
@RaananW Your solution for #1 is exactly my thinking as well, so that may be what I have to do. It seems like the behavior would be implemented natively, since it exists for regular scene picking/multipicking. For #3, it’s not that the objects are large, they’re fairly small and low-poly (see morterra.com). The problem is that quite a few of them load in at once, and as they load in the frames drop significantly, probably because the cloning is synchronous with the scene rendering. It wouldn’t really be possible to anticipate the objects to load them in before, because they are being sent by the server as you load the next chunk. BUT, you could use that same logic to trigger the load, but only display them as they complete. I figure there should be some native behavior similar to this, as many games use chunking. I’ll see what I can come up with and get back to you. Thanks again for the help!
Okay, so I fixed #2 for myself, but it could easily be a problem for other users going forward - here’s what I have learned: I realized that it was only happening with the meshes that I had rendering for my login screen. Every mesh I loaded in was either displayed on the login screen, or I setEnabled(false) on it. So while roaming in the game, if I positioning the camera just right, a specific mesh would flicker (all of them would). I tried disabling the specific meshes from the login screen and it worked. My idea is that for some reason instanced meshes don’t use their own frustrum calculation?
For anyone coming across a similar problem in the future, setEnabled(false) on the original mesh will stop the instanced meshes from disappearing.
It loads in with the error happening (or it should). I hard coded the camera position/rotation to start with the glitch happening. If you move the camera around a bit you will see the trees re-appear. It only vanishes if you have the camera in perfect spots.
One thing I noticed, it happens when the original mesh is at the exact edge of the screen. It does have something to do with the fulcrum check, I’m guessing it’s some sort of edge case…
Anyways, this took me a while to whip up, if you want to return the favor, feel free to throw together a multiPickWithSprites for me (I suck with git, PR’s, and never used typescript so it’ll be a pain for me to add it, when it should be straight forward )
EDIT: Okay, so I just realized, I had my chrome console open when I hard-coded the camera configuration. If you want it to work on load, make sure the render canvas is 700px width. Otherwise, just slowly rotate the camera around (with the original tree - off in the distant left), and it will eventually flicker the models.