Enable tracking of terrain/object meshes

[fenomas]

world should emit an event when a chunk's terrain or object blocks get remeshed, and expose a way for the client to get all terrain/object meshes in some given spot. The use case is to enable doing Babylon-specific things to the meshes (e.g. specify whether they should be affected by a local light source).

[ghost]

I think lighting should stay away from noa engine ,because lighting is computer intensive , wath you should is before placing a block do getblock(x,y,z) and getblock(x,y+1,z) getblock(x,y+2,z) if 2 blocks above are solid color of placeblock(grass, color:grey) if 3 blocks above are solid placeblock(grass,color:black) thats wath minecraft uses , there is no light in minecraft for a good reason, the game would lag to a halt

[EliteAsian123]

@nabilove Minecraft does not use the color:grey and color:black system, it has a simple light engine, and most of the shadows pretty basic. Light in games is only intensive, because rendering light is very complicated. Minecraft's lighting system isn't really complicated. So a very simple light system would be cool in noa.

[ghost]

I agree with you EliteAsian123 noa engine with shadows would be epic , but we need to figure out a way were the fps will not take a hit , I think my system would not affect the fps , between me and you noa engine fps compare to minecraft fps is pretty slow , but lets figure it out , cant wait to see wath Andy will do ...

[fenomas]

Hi, just so we're all on the same page there are two different kinds of lighting being talked about. This issue is in reference to the idea of creating Light objects in Babylon, which BJS shaders would use to render the world. This isn't feasible to do right now, due to noa not having any way for a game client to track the terrain meshes in the world, so this issue is to add a simple API for that. The change doesn't actually directly involve lighting, it's just an informational API that should make it possible to do some experimenting with lighting.

Lighting in minecraft, as I understand it, is a whole different beast. Each voxel has an int (0..15) value for its light level, that's packed into voxel data at worldgen time. Then when terrain is meshed, that value is baked into the vertex colors or materials, so no local light objects are actually present at render time. (At least that's how it all worked when last I looked at minecraft, which was 5-6 years ago.) This would be possible to do in noa, but it would be a big bunch of complicated work.

[ghost]

can we help give a a file name a clue antything , ill try all combination lol , im dreaming of this update , the lighting engine is minecraft is AMAZING!!!

[Pandawan]

I did something similar on my fork but hardcoded the lighting system rather than using events (especially in addMeshToScene on line 252). Is this what you are talking about?

If so, I think what you propose would be a nice addition!

[ghost]

Pandawan did you figure it out , I went to your fork I couldn’t find anything to try

[Pandawan]

Hey @nabilove, if you're looking for a way to get lighting in your world, the commit I linked above allows noa to support multiple lights.

This commit does three important things:

1. Adds a lightIntensity option, which allows you to customize the intensity of the main "Hemispheric" light used by noa. I added this so I could reduce that intensity and make the in-game lights affect the world more.
2. Adds a maxSimultaneousLights option, which tells newly created Standard Materials the maximum number of lights that they can be affected by. (By default, Babylon only allows 4 lights, but this can be increased tho it might reduce performance. I set mine to 8 and am getting relatively good performances).
3. Most importantly, it allows chunks to receive shadows with mesh.receiveShadows = true from lights. (This is where this GitHub issue would come in).

From these changes you can then create any Babylon light and the terrain should be affected by the lights.

In order to allow for more lights and better performances, I also used the light's includedOnlyMeshes property, which is why this GitHub issue is important.

// Don't copy this code exactly, it might not work with the way you have things setup.

// Get nearest chunk to light's position
const nearestChunk = game.noa.world._getChunkByCoords(...position);

// Get that chunk's mesh and add it to the list of affected meshes for that light
light.includedOnlyMeshes.push(nearestChunk._terrainMesh);

This entire process would be much easier if, as @andyhall suggested, there was a way to add an event listener whenever a chunk was remeshed.

[fenomas]

Hi, I don't have any changes made for this yet but I wanted to confirm that what you're describing is exactly the use case I had in mind. This is the kind of thing that ought to be possible to do without forking the engine, so I'll try to get this supported.

Let me know please if you have any particular ideas about what the "right" API would look like. My default guess would be something like:

var box = new aabb([0, 0, 0], [5, 5, 5])
var list = noa.world.getTerrainMeshesInAABB(box)
// returns an array of Babylon meshes for all terrain whose chunk overlaps that AABB

noa.world.on('terrain-mesh-updates', (mesh, box, oldMesh) => {
   // called before oldMesh is disposed and 'mesh' replaces it
   // box is the AABB of the chunk the mesh is associated with
})

I haven't thought deeply about it, let me know if those cover your use case!

[Pandawan]

Hmm, seems like a good way to go about it. With that, I could set the mesh.receiveShadows AND add that mesh to light.includedOnlyMeshes at once.

Some quick questions: Would the box AABB be in chunk or world coordinates? (That would have to be documented in some way). Also, I think it makes more sense for it to be terrainMeshUpdates since other events are camelCase.

One last thing, if world has a chunkChanged event, wouldn't that be kind of confusing to also have terrainMeshUpdates, which essentially represents the same event? The terrain's mesh would never update other than the chunk being updated right? So maybe consider merging both of these? I'm not exactly sure either because merging would result in too many parameters being passed to the callback so idk

[fenomas]

Hi, sorry for the late reply! I haven't gotten to this yet, but to answer the questions.

Thanks for the reminder on the name. The event would issue world coords - I've tried to keep chunking as an internal abstraction that game clients hopefully don't need to think about.

About chunkChanged, I think that used to be used internally, but seems to be unused now so I'll probably remove it. Either way I would make a new event for the mesh thing though, to have the proper semantics. That is, "chunk's voxel data changed" is semantically different from "a mesh has been removed or added", even if in practice they always happen at the same time.