Uniblocks: cube-based infinite voxel terrain engine

Here's a basic script for falling blocks. I included comments in every line to explain it in detail, if something is still unclear please feel free to ask.

Attach this to the blocks you want to fall, replacing DefaultVoxelEvents. For clarity I removed all unrelated functions (like removing grass on blocks below). Also, the OnBlockDestroy part should generally be included in all placeable blocks (even blocks that don't fall themselves), but I wanted to limit it to just one script for clarity.

Basically, each time a block is placed or destroyed, it checks if it or the block above should fall down. If a block does fall down, it is moved one voxel down and triggers the check again in the new position. There is a short delay before actually moving the block for a nice falling effect, using coroutines.

http://pastebin.com/GU2T7x23

 

Thanks Alot Maap This is awesome!!
I did Have a small Error But i managed to fix it!!
Again Thank You this was a HUGE Help

Also is their a way i can use this so that it updates the blocks that get Spawned in the world And not just when they are placed ? Thanks
Update* since i made this post i managed to Get it all working i just added most of the OnBlockDestroy Function from the sand physics and added it to the defaultVoxelEvents!

 

Thanks maap, I've got it working perfectly now. For some reason I was thinking that voxelinfo was a voxels local position inside a chunk, don't know why I thought that. I realize now its a voxels world position, and i didn't even notice the GetVoxel method in voxelinfo, so thanks again.

 

Hey there,

Still keeping an eye on this. I've been making my own engine, but still interested in purchasing this to make my life a bit easier.

Now that you released an update, how are the plans for future support/updates (including new features) looking? Essentially, if there aren't many plans, then I feel I'd be better off taking the time to continue with my own. But if there are solid plans for the future, I'll probably buy it today.

 

Sorry I wasn't able to respond earlier, glad it's working now!

VoxelInfo is basically a reference to a specific, unique voxel in the worldspace. The index it stores is in fact the local index within a chunk, because there are no absolute voxel indexes anywhere (it would be impractical since the terrain is infinite), but the local index together with the chunk reference (which is also stored in VoxelInfo) allow you to identify a specific voxel in the world.

Currently there are no plans for any major updates in the near future. Of course minor updates for bugfixes and such will continue, and I'll continue providing support to customers.
I don't really want to comment on any long term plans, because they're really not solid enough and will depend on future circumstances. Definitely no plans to abandon the project, I just don't want to make any promises that I won't be able to deliver on later.

By the way, in case you do decide to buy Uniblocks, please wait a few days before the update is officially up on the asset store, since the price will be reduced to $60 (it's currently still pending approval).

 

Sent you an email yesterday dude.

I'm interested in the possibility of augmenting our current blocks system with yours if it turns out to:

1) Be able to integrate with our existing Photon server
2) Result in being more efficient than our in-house solution.
3) Save time

But i'd need to have a conversation about it instead of just over forums because there are a lot of technical questions involved.

Thanks for your time!

 

Hi maap,

how do I detect in a collision if the collider is from a block / voxel?

Is there a Special tag or something?

Thanks a lot and have a nice Weekend!

 

Take a look at the Chunk prefab and you should be able to add a tag or layer if there isn't already one assigned. Then you can just reference these as this prefab is what gets instantiated

 

Thanks for the hint. There is no tag yet.

Background: I just added NPC / Monsters to my uniblocks world and they are already running around.
But when they run into a wall, I want them to jump or Change direction.

What is the best way? I just saw ColliderEventsSender, can I use that somehow for detecting walls?

Or should I add a tag for voxels?


Thanks a lot

 

ColliderEventsSender is used to trigger OnBlockEnter and OnBlockStay events. These only happen when your object enters a block, so it will usually only work for blocks with no collision (like tall grass, etc). That means it's probably not useful for you in this case.

If you only need to know if any block was hit, not necessarily which specific block, you can just tag the Chunk prefab and use normal OnCollision and CompareTag to detect the collisions.

If you need to know specifically which block was hit, you could the Engine.VoxelRaycast function. It works like a regular raycast but returns a VoxelInfo which points to the block that was hit (or null if no blocks were hit). When a collision happens, do a VoxelRaycast from the object's center towards the collision point, and if it returns a VoxelInfo, you'll know that a block was hit, and you'll have the reference to that specific block.

 

Heya Maap just a quick Question is their a way to Delete more then 1 block at a time like say 4 x 4 rather then just 1x1 ? Thanks!

 

Quick question - I notice out of box there is a distinct line between each block. It looks like the texture is slightly too small for each box but it creates a nasty look with jagged edges when the textures on the mesh aren't solid against one another. Is this a feature or should I bug hunt this down? Just asking because for $75, just thought something like this might be fixed already!

 

There is no one function for deleting multiple blocks, but you can just do a simple for loop to run the DestroyBlock function on multiple blocks.

This example will destroy all blocks inside a cube of the specified size. "voxelInfo" stores the origin voxel in this example, and the cube is determined by adding 1 to each coordinate

Code (CSharp):

1.                 int size=5;
2.                 for (int x=0; x<size; x++) {
3.                     for (int y=0; y<size; y++) {
4.                         for (int z=0; z<size; z++) {
5.                             Index newIndex = new Index (voxelInfo.index.x+x, voxelInfo.index.y+y, voxelInfo.index.z+z);
6.                             VoxelInfo newVoxelInfo = new VoxelInfo (newIndex, voxelInfo.chunk);
7.                             Voxel.DestroyBlock (newVoxelInfo);
8.                         }
9.                     }
10.                 }

Disabling anti-aliasing in the quality settings should fix this problem. You can also try switching to deferred rendering instead (in the player settings).

 

Thanks for the quick reply! I've done as you've said but this does not make a difference. I've swapped the texture to solid colours for you to see the spacing issue. I've tried disabling AA and also switched to deferred rendering. It seems like the textures on the meshes aren't aligned perfectly or the meshes aren't drawn in perfect alignment. The texture is set to point. To disable AA seems like a huge cop-out and unfair to developers spending $75 on this addon. Without AA, the cubes look jagged and are not nice for the player to look at

 

If you're using a custom texture, make sure its filter mode is set to point and mip maps are disabled. Lines like in your screenshots are almost certainly because of mip maps.

You can find the correct texture import settings in this post:
http://forum.unity3d.com/threads/un...ite-voxel-terrain-engine.226014/#post-1524793

If you're still seeing the lines with the correct import settings and/or the default texture, that would indicate some problem with your settings somewhere. Do you see the lines in the demo build? If so, it's most likely something like forced anti-aliasing enabled in your display driver settings. If you're seeing the problem inside your Unity project but not in the demo build, it's probably something to do with your project settings. Perhaps try importing Uniblocks into a fresh project, changing the AA settings and nothing else?

 

Hello Friend. I been looking into this project and I also noticing the lines. Mostly vertically but as you can see they also happen horizontally. This is 100% via the Demo with 0 Forced Settings from my Nvidia Card. Not sure what the above users card is.



This is quite a big issue I think. If this is happening in just a normal sitting you can't expect most users to have to play around with their video settings for hours and hours. If your releasing this in a game to the public it would go south quite fast without a solution.

From the loading speeds etc of the Generation things are great but this slight rendering issue would need to be looked into.

I'm going to look into other voxel scripts tonight and maybe if there is a Opensource one that has no issues I can refer you to it.

Thanks,
Kane

 

Ohh i see, Thank you Very much for The Example i would have had no idea otherwise

 

Code (CSharp):

1. Debug.LogWarning ("Uniblocks: Anti-aliasing is enabled. This may cause seam lines to appear between blocks. If you see lines between blocks, disable anti-aliasing in order to get rid of them.");

This is in the Engine.cs - do you not find int problematic that AA is not supported? It makes the mesh edges look very jagged and low quality. I really hate to say this but for $75 again I kind of find this to be a little bit of a punch in the stomach. For me, I just paid $75 but that is just about $100 CAD and I'm already on a budget - but now finding out the entire addon is not compatible with AA makes me regret this purchase. Any chance on a fix for this?

 

If you zoom in and look at the edges of the blocks, the screenshot you posted looks like it does actually have anti-aliasing enabled. It's saved as a lossless png so it doesn't seem like image compression artifacts. I would really recommend you double check your settings!

If that doesn't solve the problem for you, I'm really sorry, but unfortunately it's impossible to guarantee that any software will work exactly the same on every single system. In this case in particular, it's a rendering issue with Unity that I have nearly no control over. The solutions I provided (disable anti-aliasing, check texture import settings, switch to deferred rendering path) should work in theory, and have worked for every user so far, as far as I know, but I'll continue looking into this issue, it's possible there's something I missed.

Switching to Deferred rendering path should enable you to have anti-aliasing enabled in most cases. If it doesn't, sorry, but there's probably not much I can do. Again, I'll continue looking for a solution, but honestly, it's been like this for 1.5 years so far, so I don't know if I'll be able to find anything...

I agree that AA not being supported can be a problem, I will include this information in the OP of this thread. I haven't really had any complaints about this before, so honestly it just never occurred to me before.

 

Heyy maap, i have Two Questions the first is how Exactly do i go about get The Exact bottom Height of my world im trying to Create Bedrock and also im not sure if this question has been asked in the past but the lighting i added to the Scene seems to be going through the blocks so when you go mining for Example its not Exactly "dark" the light seems to be passing through the blocks i have tryed making the shadows more intense but it still dosent effect what im trying to fix - Thanks in Advance

 

The world is actually infinite in all directions, so technically there is no absolute bottom. In theory, you can just choose any height and put your bedrock layer there. However, chunks will only be spawned up to a certain depth depending on the chunk height range setting and the size of the chunk. For example, with chunk size 16 and height range 3, the bottom layer should be at -48 (3 chunks down * 16 voxels per chunk = 48)

In the example terrain generator scripts you have a variable called currentHeight, which stores the absolute world height at the current voxel, so you can use that to add a line which sets the voxel to bedrock if currentHeight is -48, for example.


As for lighting, I don't know if I can help you here... Uniblocks doesn't actually do anything with lighting, it all depends on how your scene and lights are set up. Maybe your ambient light is too bright?

 

Hi Maap,

I have Uniblocks multiplayer set up and running (I converted your scripts to PUN), however the server crashes fairly quickly after a client connects. I believe it is because the server is sending out too much data, too fast, to the clients.

This is the warning I receive before crashing :


Since SendVoxelData is called for ever single chunk, that ends up getting called many times - however many chunks you have configured. For me it gets called 1765 times (I believe due to having a spawnDistance of 7), all right around the same time (since we're looping through chunks). It's simply too many calls at one time.



I tried increasing the chunk size to 32, since bigger chunks == less chunks, but the processing per chunk takes so much longer and really just doesn't work well. So I'm wondering if this large number (1765) is expected behavior, or if I'm spawning too many chunks / making too many requests accidentally due to having a chunkspawner on the wrong player, or something along those lines?

If this is just a current bottleneck, then maybe we can write a different way of sending chunk data. Perhaps we could "chunk the chunk data" - send an array of chunk byte[]s instead of one at a time. A much faster, yet unreliable method of sending chunk data could be to only send the voxel changes, and then just let the clients generate their own terrain based on seed and then apply those changes. What are your thoughts on this?

 

Ohh i see thanks maap managed to get the bedrock working and as far as the lighting taking down the ambients helps a fair bit Thanks for your Help!!

 

Spoiler: Pictures

I don't seem to have any of these problems with anti-aliasing enabled.... I feel like I am missing out

 

1765 is the expected number of chunks with your settings, but it definitely shouldn't be crashing your server!

My guess is that the client is sending the requests way too fast. Normally, the client is supposed to load chunks gradually, distributing the load across multiple frames to maintain steady performance, but it doesn't take into account the server's performance, so this could lead to a situation where the client requests chunks too fast for the server to keep up.

One way to deal with that would be to slow down the loading on the client side to give the server some more time to handle the requests.

Can you maybe try adding this line:
yield return new WaitForEndOfFrame();
in ChunkManager's SpawnMissingChunks function, after all three Instantiate calls?
(basically, wait until next frame after spawning each chunk)

This isn't really a solution, but if it does prevent the crashes, it will confirm that that's what causing the problem, and I'll work on a proper fix to this.

That could work, but I don't know if's necessary, seems like the problem is more about the amount of requests rather than the size of the data. The data is already sent compressed, which really shouldn't take that much space in most cases. Still, it might be worth it if you absolutely have to optimize the amount of data sent over the network.

 

That's good news!
I'm curious though, do you have your rendering path set to deferred or forward? (in your project's PlayerSettings menu).
Generally you shouldn't have problems with anti-aliasing enabled on most systems as long as your rendering path is set to deferred, but it would be even better if it works for you even with forward rendering.

 

This does indeed fix the crashes. I had a workaround that would add the chunk requests to a queue, then dispatch them in chunks to their associated playerId. It works, but it sounds like you may have a better idea. Sending them in chunks greatly reduced the request count, but the queue certainly doesn't feel super elegant at the moment.

Yes, the problem is definitely the amount of requests as opposed to the size of the data. Even if you sent the initial World load chunk data (1765 chunks, for example) in one request, I don't think Unity (or at least Photon) would have a problem with that.

Looking forward to a fix for this, but the frame skip and queue manager will get me by for now.

On a side note, I've been working with this engine pretty extensively over the past few weeks, and I must say it has been an absolute blast. Very well written, easy to understand, well-commented, and the new update really improved performance. I suspect there may be some room for multi-threading when calculating mesh data, but that's just a hunch and right now I'm very satisfied with Uniblocks. Great job, and fantastic support. Thanks!

 

I've tried disabling AA, custom import texture with disabled mapping, as well as forcing deferred rendering instead of forward and just to be on the safe side triple checked my texture sheet to make sure, but I still get these lines no matter what I do.

 

I do have a few ideas. The simplest thing would be to just locally count and limit the number of requests sent by the client per frame. This would be a bit better and more elegant than the current frameskip hack, but would require adjusting manually to set a good limit.

A better way would be to dynamically adjust the number of requests depending on the current server load, but this would be more complicated and would require some feedback mechanism from the server instead of being purely local.

A batching system like the chunks of chunks you talked about might also help, but I suspect it might cause some problems because of the extra complexity - dealing with each chunk individually in isolation is a more robust and reliable way, so I'd probably prefer to keep it this way unless absolutely necessary.

I'll be working on the solution and will get a patch out as soon as I can. Unfortunately I'm super busy this week, so it's probably going to take a little time, but it's definitely coming!

Thank you!

I was actually experimenting with multi-threading a little, but it seems a lot of the performance cost comes from the Unity's Mesh functions (setting vertices, etc), which have to be executed in the main thread. But yes, some parts of the mesh creator, like looking up voxels and building the lists of vertices and faces, could probably use multi-threading. I haven't worked on it yet because it would definitely take a lot of time to do, and I can't know for sure whether the performance increase would be that significant. It might happen in a future update sometime though!

 

Does this happen in the demo build too, or only in your project?

If it happens in the demo too, make sure that you don't have any forced anti-aliasing enabled in your graphics driver settings, but other than that, I really don't have any solution for that at the moment.

If it's only your project, it has to be something with your settings somewhere, which would be good news because that means it can be fixed. The texture looks like it's somehow not aligned properly (bottom edge of the rightmost block, for example), maybe it has something to do with that... but honestly, if your texture import settings are correct then I can only guess.

If you could send me a project in which the issue happens, I could then try to figure out what's wrong. It doesn't have to include any of your game assets, scripts, or anything, just whatever is necessary to reproduce the issue, so probably the texture, material, and the project settings.

 

Well it's both, if the filter mode in the sheet is set to anything but point whether AA is on or off it does it also. If it's set to point and AA is off it's fine. This does pose an issue as I have textures ranging from 128 to 2048 in size and a lack of AA will at some point be an issue, as I already begin seeing the lines within my textures. Is there anyway to improve the graphics quality without causing this issue?

 

I am trying to find the code that causes the player to shoot up in the air when the player hits the collider. Thanks

 

What exactly do you mean? The demo is probably using unity's default character controller and physics. If you're running at high speed and hit a collider you're going to launch up a bit. What were you looking to do?

@maap Btw, I looked around on the forums but I can't find your answer, is there a way to limit the total vertical generation? For example I want to generate about 12 chunks in height from the floor up. Like most "voxel" games I need features based on that height as well. Is the chunk index the proper method for finding that?

 

In uniblocks 1.2 if you created a block on top of yourself, you would fall through the terrain. Now in 1.4 if you create a block on top of yourself, you bounce to the side. However if it is under you, it will pop you up very high in the sky. Like so high you can barely see the map. I want to reduce this height to just pop you over the block.

This is what I do for heights:

int currentHeight = y+(SideLength*chunky); // get absolute height for the voxel

Then where you hit mouse 1 to place the block use (defaultVoxelEvents.cs):
if ( mouseButton == 1 && currentHeight <= 12){

...rest of code to place block
}

 

Ah I see what you mean, there's a couple of options for that. As for the height, ya I know there's multiple ways of checking height itself, both in the chunk and the world, but what I'm concerned with is the chunk generation, I want it to stop after a certain height, the params in the engine are just for how far/close. Where I want to stop the chunks random generation after about 200 or so.

As for the popping issue; you can either run some checks to prevent a player from doing so, or you could use unity's physics to force a certain movement ignoring the normal physics systems. (Such as temporarily altering the player's RB settings and forcing movement then setting em back.)

 

Unfortunately at this time Uniblocks requires certain settings to prevent the lines from appearing - point texture filtering, and either deferred rendering or no AA.
I might have a solution for the texture filtering setting, which would allow you to use settings other than point. A patch including the fix is possible sometime in the near future.

There isn't any code that does it, it's just the Unity's physics engine. It seems that if you place a collider on top of the player, the player will be pushed outside of it.

The reason that there is no code that would prevent placing blocks on top of the player is because I wanted to keep the demo as simple as possible, without too many extra features. If you're building a game using Uniblocks, you'll probably want to implement your own player controller and block placing system anyway.

Are you maybe looking for the "chunk height limit" setting (in Engine Settings)? It limits how many chunks can be spawned vertically, so for example a setting of 3 spawns 3 chunks below, 3 chunks above, plus the origin chunk, so 7 vertical chunks total. These values are absolute, so the lowest chunk will always be absolute y=-3, and the highest will be absolute y=3.

Otherwise, you can just hardcode some kind of a height limit for generating voxels in the terrain generator, by checking the chunk's y index (or absolute height of each voxel) and leaving them empty if they're above your limit. This would mean that chunks still get spawned and can have blocks placed or destroyed during gameplay, but terrain wouldn't be generated for them.

 

Well what I'm personally doing is modify my textures and sheets to fill the areas around each image with near-pixel-perfect color to make sure there's a bit of a bleed. As long as the mapping is turned off even with AA on I don't get lines.
(See my attachment.)

@maap
Ah, see I dug a giant hole and didn't go all the way down I guess, I thought the "L Height Range" wasn't absolute but relative, and I could then always continue to go down. Which also worried me for underground features because things like stones and resources that will fill up caves and such I'd have to always translate the position to work coords. Thanks very much for clearing that up.

Edit: So I ran into a bizarre issue, when doing my passes in the custom world gen I'm adding all kinda of new blocks and features etc. But Only the grass and dirt can be removed by the editor script in the demo scene. Any clue why? I checked the script and the block window don't see any special flags I'm missing. They're exactly the same as dirt is.

 

Make sure the block object prefab that was created (Uniblocks -> UniBlocksObjects -> Blocks) has the "DefaultVoxelEvents" script attached to it. That should do it.

 

Ya that was it, didn't think to look at it because it hadn't done that wrong before.
@maap Might I make a suggestion; could there be an option to offset a block's placement spacing?
Custom meshes for example get placed dead center, I have a couple that have pivot points at the bottoms and
tops so when placed they wind up in the middle of a block.

Also, in the inspector when you add a new block it starts in the 70s someplace, and each time after that even if you change the engine's array number to something like 3 and delete the other block prefabs, and change the ID on the block you're working on. It's really nothing important, just didn't know if you had a tracker or someplace to put that.

 

That was pretty much how I wanted to fix it too. A built-in "texture padding" setting to get rid of the texture bleed from the neighboring block textures. It would adjust UVs to create pixel-sized gaps between each texture, so hopefully you wouldn't even really need to modify your textures.

Wouldn't it be much easier to just move the pivot point of the mesh directly in a 3d modelling program?
It seems to me like a pivot offset setting would only add extra complexity and clutter in the settings, when opening the mesh in a modelling program and moving it to the correct position manually is much easier and simpler. I don't know, having the pivot always in the center of the block just makes sense to me...

Pretty sure it shouldn't do that. Adding a new block should always set its ID to be 1 higher than the current highest ID. For example, if you delete the block 70, and then add a new block, the ID should be set to 10, assuming the remaining blocks go from 0 to 9.

If your new blocks start from 70+, that probably means you still have the ID 70 block somewhere. When deleting blocks, make sure you delete the prefab from the /UniblocksObjects/Blocks folder.

 

Ya it'd be handy, I'm sure not everyone's gonna know how to carefully fix their textures or want to change them.

No I certainly agree with your opinion, just a thought. Also, because I plan on having objects that take up more than one cube of space, it would mean that if an objects takes up (for example) 2 blocks on the xplane, the anchor dead center would mean it would take up one whole block, then 1/2 of each besides it. I'll probably end up adding them to the world via instantiate anyway since most are persistent.

Ya I'm just deleting them after I renumber them, it's honestly not an issue, just figured I'd give all the feedback I can. Really like this system so far.

 

Hello maap

two questions: could it make sense just to add another ushort value to a voxel for multiple Options: depending on the voxel and the used range it could be used as a lifetime or grow Counter, an additional water or Lava Level, even a second base block or whatever. I would find this extremly useful, what do the others think?
Just adding it, saving and loading it. Just to use for whatever.

and a how-to question: my Lava should glow. I already use a list already for my lights (torches, fire basins), but the Lava is in some Areas much more often. And it can fall or flow in my case. Can I attach a light somehow or should I add it to my light list and update it there, too?

Thanks a lot

Firlefanz

 

@Firlefanz73 That is one loaded question. I can't comment on the first obviously, but knowing that chunks are completely deleted from the scene outside of view then re-created you would have to find a way of holding that data unless he changes anything. I personally think it would be neat, or have some builtin way to save at least persistent data by chunk and block. Right now I'm using dictionaries as I prototype it out, but Idk how well that'll work after a while.

As for the lava glow, not quite sure exactly what you need to know. If you're asking about falling and flowing you can look at the system by @Ellandar that works with Uniblocks. You can also attach a custom shader to a material and separate that block from your normal material list. If you're talking about using uniblocks and having a glow emit from the block you could create a voxel event or attach a script to use OnBlockPlace() to tweak the lighting around it or create a light. Really depends on how you plan to do it and how you're doing it already. Hope that helps.

 

Hi. Uniblocks looks good but my main concern is the obvious and visible tiling. In most cube-voxel based games, the texture UVs are continued across multiple blocks to fix this. How would you do this in Uniblocks?

 

Hello,

does anybody have an idea what I am doing wrong here:

In a script attached to the Player I want to update the chunk I am in (with own update method):

Chunk chunk = ChunkManager.GetChunkComponent ((int)transform.position.x, (int)transform.position.y, (int)transform.position.z);
//GameObject ch = ChunkManager.GetChunk ((int)transform.position.x, (int)transform.position.y, (int)transform.position.z);
if (chunk != null && chunk.isActiveAndEnabled)
{
currentChunkUpdateTime = 0;
chunk.Update ();
}

chunk is null evertime and always. Should be working? The transform Position Looks ok for me...

Thanks!

 

Dunno dude, I'm still waiting on a response to my own question.

 

It depends on what you're trying to achieve. The simplest way would be through the Engine methods.

Code (CSharp):

1. Chunk chunk = Engine.PositionToChunk(gameObject.transform.position);

If you're just trying to see if the chunk is there, if (chunk != null) is enough, as if you're standing in it, it would have to be both active and enabled, just for it to not return null, so it's a bit superfluous. From there you can get voxels in the chunk, and even access it's own index just by chunk.ChunkIndex; Mind you this is from memory I'm not at my dev box, and PositionToChunk gives you the GO, so you'll need to fuddle around to get the reference.

 

Hi everyone, sorry about the delay in replies, I've been away for a few days and just didn't have any time or opportunity to respond properly.

That would make sense, yes. I was considering it during development, ultimately I abandoned it for some reason, possibly because I was worried about memory usage, since with an additional ushort for every voxel the world would take up twice as much memory. But on second thought, I think I want to try to add this system in somehow in a future update.

Currently you can kind of do something like this already using multiple different blocks with their ID digits storing the extra information, like with the door example (id7 = closed, id70 = open), but a more elegant solution would definitely be nice to have.

Like @TheXWolf said, the lighting for lava can be approached in many different ways and it's hard to recommend anything specific. However, you will run into problems if you have too many lights in the scene, so attaching a light to every lava block is probably not a good idea. Maybe you could try having only one light per several lava blocks and adjust their brightness/range depending on how many lava blocks are around?

The arguments (x,y,z) in ChunkManager.GetChunkComponent should specify the chunk's index, not the world position. This means you will have to convert the player's position to a chunk index first, using Engine.PositionToChunkIndex, and then use the returned Index in ChunkManager.GetChunkComponent.

Alternatively, you can just use Engine.PositionToChunk directly. This will return the chunk at the given world position.

Uniblocks currently doesn't have a system to handle that, so unfortunately it's not easily possible, unless you use multiple separate blocks with different textures.

 

Will there ever be support for a sprite configuration for the block type? Also, I sent u a PM if u have a min.

 

Do you mean the tiling texture problem from the previous post? If so, it's possible, but there are no specific plants right now.