Changing skybox about noa HOT 18 CLOSED

Hi,

This is great as a code sample! However, it falls into the big category of stuff I'd like to leave out of this particular engine.

Basically I started out building this as a "general game engine", but over time I came to understand that the scope would be endless, so in order to keep things manageable I'm trying to limit this library to only managing voxels, and things that are tightly coupled to them like physics and meshing, and leave everything else for the "client" app.

So, I want the client to be able to grab a reference to noa.rendering.getScene(), and add a skybox, lights, god rays, fog, extra cameras, or whatever they want. But I want to avoid having a lot of code in this repo for handling such things since they aren't coupled to the voxels.

With that said, it would be totally reasonable to build stuff like this into some kind of wrapper project, that lives on top of noa and exposes features to make it easier to build a certain kind of game, or something like that. I would certainly support/link to a repo like that 😄

Hope this makes sense, and thanks for understanding!

from noa.

from noa.

Hmm, I've never used skyboxes in BJS, sorry! But I'm pretty sure I know the problem - you need to call noa.rendering.addDynamicMesh(mesh). (There's no way you could have known that though, for which I apologize!)

The reason is that I'm using Octrees for the scene, to speed up Babylon's frustrum culling against all the terrain meshes. So this means that any mesh that isn't part of an octree doesn't get rendered. The API adds the mesh to a special array of meshes that get tested independently of the octrees, and it also adds a hook to the mesh's dispose method to remove it again. Sorry you tripped over that, I should really figure out better ways to document this.

For the rest, stuff like inventory and items are definitely what I'd consider "client game" stuff. Don't misunderstand me, I'd be really happy if you write such things and release them! But I want modules like that to live one level higher than noa, so that it's scope stays in check.

Movement and player mesh are an interesting spot. Right now both of them are sort of built into noa. If I was doing it all over again, I think I'd leave them as separate, and keep this engine more narrowly focused, but at this point it would be a pain to remove them. So what I'm trying to do now is just keep them where they're at a level that's basic enough that you can use the built-in functionality for a quick demo, but you can also remove the built-ins and replace them for a Real Game.

(Specifically you should be able to do this by removing components from the player entity. E.g. the player has a component called receivesInputs that hooks up keyboard inputs to the physics movement stuff. If you remove that, noa would stop trying to control the player and you could move him via some other paradigm.)

from noa.

Okay, as for stuff I'd like help with. I think the biggest value / easiest thing would be to have some helper modules that work well with noa but don't need to be core parts of it. One example would be serialization. In my own game I found this to actually be pretty easy - basically I just listen for chunkBeingRemoved, and every time that happens I grab the chunk's ndarray and compress it (with this repo). Then, when a new chunk is requested, I check whether I have the data stored or not, and if so I return it, and if not I generate new data.

Now for me, the way I do all that is tightly coupled with other stuff in my particular game. But a general module for it would be useful as something that lived above noa. (Actually if it can be done so generally that it makes sense for pretty much any client, then it would make sense to put in the core engine - if not then it makes sense to live separately. I haven't done any deep thinking about this..)

Does that make sense? As for really core stuff, there are certainly things I'd like to support that I haven't got time to think about - one would be blocks whose (physics) hitbox doesn't take up their full voxel. Another would be the idea of voxels having an orientation (like whether the block faces North or East). Or an extreme feature would be blocks that invoke some kind of custom, client-specified meshing behavior, the way (e.g.) water and lava do in minecraft.

But features like those would dig pretty deep into parts of the engine that I've spent a long time tuning. So if you want to take a stab at them it would probably be best to discuss how to approach it in issues first.

from noa.

Adding that line worked like a charm!
So, to add anything to the world, I need to send it to noa. Great to know :)

At the moment some things that are in my personal roadmap are:

• Change the shape of the map (currently I am using data.shape)
• Player mesh + skin
• Player movement animation
• Liquid physics
• Save/Load custom maps
• Adding mobs with AI
• Physics for meshes over blocks (e.g. if a block is broken under a flower, it should break as well. Since that's how I remember Minecraft behaving)

from noa.

Hey, thanks for the info. Most of those features sound great for client or helper modules. Liquid physics is something I haven't thought deeply about - what's in the engine now is kind of a quick hack, and I think I will probably wind up not putting fluids in my game (for now, anyway) so I don't have it high on my agenda. My gut thinking is that it's not an interesting feature to have until there's some better way of rendering fluid-like blocks.

For block-breaking stuff, I think the way to go is probably to have some kind of "blockChanging(oldID, newID, x, y, z)" event, where the client can listen for that and handle whatever special cases it needs to handle. But I'm not currently using such a feature, and I try not to implement things until I'm ready to use them. Would that cover what you have in mind?

from noa.

Probably that might work :)

Btw, is there any event for when the player (or any entity) gets in contact with a block? Or some sort of internal structure for setting the durability of a block (e.g. the stone block needs 5 hits to be broken), together with changing the texture accordingly (e.g. partially broken block)?

Or do you think that should be handled by the client as well? (it might require some knowledge of the internals, I guess)

from noa.

Also:

I tried creating a babylon box and adding it to the world but it just doesn't show up. I thought that using this would be enough:

let myBoxMesh = BABYLON.MeshBuilder.CreateBox('SuperBox', {height: 5}, scene);
noa.rendering.addDynamicMesh(myBoxMesh);

Am I missing something silly?

from noa.

Btw, is there any event for when the player (or any entity) gets in contact with a block?

The only events related to blocks right now are for when they're set/unset or loaded/unloaded. However there's a collidesTerrain component, which gets added to the player entity by default, and calls a callback whenever the entity collides with terrain, which might be of use?

internal structure for setting the durability of a block (e.g. the stone block needs 5 hits to be broken), together with changing the texture accordingly (e.g. partially broken block)?

Nothing like that right now. I've thought about having some kind of "store a arbitrary object of data associated with a given block" feature - in fact I have this built into my own client app - but to be honest it's like 10 lines of code and it doesn't have much to do with the engine code so right now I've left it out.

For texture changes - it's a useful idea but I don't know what the right way to do it would be. Due to how terrain gets meshed it wouldn't be easy to change the texture of just one voxel face, so I think one would need to create a temporary overlay mesh? I don't know if there's a clever solution.

let myBoxMesh = BABYLON.MeshBuilder.CreateBox('SuperBox', {height: 5}, scene);
noa.rendering.addDynamicMesh(myBoxMesh);

I'm not sure, this works as expected for me. Maybe the mesh is being created inside terrain and you need to move its position.y upwards?

from noa.

The only events related to blocks right now are for when they're set/unset or loaded/unloaded. However there's a collidesTerrain component, which gets added to the player entity by default, and calls a callback whenever the entity collides with terrain, which might be of use?

That would be nice. I'll give it a try!

Nothing like that right now. I've thought about having some kind of "store a arbitrary object of data associated with a given block" feature - in fact I have this built into my own client app - but to be honest it's like 10 lines of code and it doesn't have much to do with the engine code so right now I've left it out.

Is that in the testbed? I'd like to see how you did it :)

For texture changes - it's a useful idea but I don't know what the right way to do it would be. Due to how terrain gets meshed it wouldn't be easy to change the texture of just one voxel face, so I think one would need to create a temporary overlay mesh? I don't know if there's a clever solution.

Or maybe create 1 block for each change and then switch the block itself with the next one? For example:

Dirt -> 1 hit -> Damaged Dirt -> 1 hit -> Air

And the sequence could be stored into an array meaning that if the block is hit with a more powerful weapon (e.g. it does twice the damage), we simply jump over the array with a greater index. This seems something on the line between being interesting on the engine as well as on the client side. I might give it a try when I get to that point :)

I'm not sure, this works as expected for me. Maybe the mesh is being created inside terrain and you need to move its position.y upwards?

Dunno, I tried to give it the same coordinates as the player (0, 10, 0) but it doesn't show up. Weird.

Anyway, I was wondering, with your current implementation, is better performance-wise to create a custom mesh with boxes and shapes through Babylon or simply create it on Blender and import it?

I am asking because I'd like to implement what these two libraries (https://github.com/flyswatter/voxel-walk, https://github.com/maxogden/minecraft-skin) are doing for Three.js, but I am having a bit of trouble as I am not too experience with Babylon yet. So, I don't know if I should through the trouble of creating a custom player mesh, doing UV-mapping and then animate it, when it could be easier and better to just do it on a proper 3D editor. What do you think?

from noa.

Dirt -> 1 hit -> Damaged Dirt -> 1 hit -> Air

This would be the least work, but it would be a pain if you have several stages of damage. Also, there's a limit to how many blocks the engine can know about (I think it's currently 256 or 512), which you might run into if you specify several damaged states for every block you want. That's why I think an overlay might be better - but there's nothing in the engine to support it today.

Is that in the testbed? I'd like to see how you did it :)

I just have a hash object, and store per-block properties in it as hash[ x + '|' + y + '|' + z] or something like that.

Regarding meshes and models, I haven't tried any of the "authoring stories" for Babylon - Blender, or I think there are some other editor type tools. People in the babylon forum might be able to help though - somebody may already have done something with minecraft-like models?

from noa.

I have ended up creating the mesh manually and now the next step is to map the texture to the meshes.

By the way, I saw in the testbed that the player floats in the water but I really couldn't find that piece of code in the repository, could you show me how you did it? :D

from noa.

Physics generally are split into a separate repo called voxel-physics-engine.

Here is the buoyancy code: https://github.com/andyhall/voxel-physics-engine/blob/master/index.js#L191-L192

from noa.

Thanks!
I noticed that you are using the module here: https://github.com/andyhall/noa/blob/8cfc5faec0bc6bd30f7b35f6db984671274dcdeb/lib/physics.js
but how do I enable the buoyancy?

I tried making a very tall pool of water and my character slowly sinks to the bottom, instead of getting back up.

from noa.

Buoyancy force depends on the fluid density and the entity's density (i.e. its size and mass). The entity will only float if the buoyant force is greater than the gravity force.

So, if an entity is sinking, either increasing the fluid density or decreasing the entity's density (by decreasing its mass or increasing its size) should help.

from noa.

Perfect, the problem was that I hadn't set the opt for playerHeight and playerWidth (since I don't use them at the moment). Once I set them, everything worked great :)

from noa.

I will close the issue as it is regarding the skybox and I just created and published this little module: https://github.com/Nesh108/babylon-voxel-skybox

Btw, I am starting to slowly convert (or create) voxel.js modules for Babylon.js, using your engine as the base (similar to how people built lots of modules for voxel.js).

Here is the thread I started on the Babylon.js forums: http://www.html5gamedevs.com/topic/29100-babylon-voxeljs/.

Let me know what you think :)

from noa.

Hey, super cool! I will comment over at the forum (I try to check there when I can).

Do feel free to keep asking questions!

from noa.