So my first test with a cube of acid just burned all the way down to the bottom of the level. My next thought was to build a pool with a floor that won't be corroded by the acid and it turned out nicely. Here you can see how that looked like after some time:

Of course also in this case the acid never would have stoped burning through the rocks

Why don't you have the amount of acid decrease every time it burns through something? That way it will be self contained, also more realistic. So If a player is mining they could run into a packet of acid (That was contained by a certain of rock) and they would either have to let to create a hole, or try to contain it.

Yes that's exactly what I was about to do. I think every block should have a value of blocks it eats through and if that number reaches 0 the acid is considered saturated.

Maybe you are right, I don't know the forum rules about that in particular but in the light of recent discussions I hope that my game is not considered just another MC clone and therefore put into "Cube Worlds Projects". But rather if "Cube Worlds Projects" is a genre sub forum, then I'm okay with moving it there.

I completely agree. It is a shame to see many voxel, world-shaping type of games quickly branded as a Minecraft clone. It is evident from the videos that you have posted that your game has quite a bit of uniqueness to it.

One could easily brand many top-down RTS games as clones of Dune, or FPS games as clones of Wolfenstein (or whatever came first). Following a genre or theme is hardly cloning.

I love the style you've started here. I'm curious since I just started playing around with cubic frameworks in JME3. How many verts/tris are you rendering textured at once? Do you import models of the blocks, assume their structure is all cubic or do you have other shapes too? (I thought I saw some slanties in there).

Man I love this. Been following the thread for a while now but never really posted.I just have a question, what method do you use for the SSAO? An SSAO shader of some sort or do you just edit the vertex color based on surrounding blocks?Thanks, and good luck

Was I before Chuang Tzu who dreamt about being a butterfly, or am I now a butterfly who dreams about being Chuang Tzu?

I love the style you've started here. I'm curious since I just started playing around with cubic frameworks in JME3. How many verts/tris are you rendering textured at once? Do you import models of the blocks, assume their structure is all cubic or do you have other shapes too? (I thought I saw some slanties in there).

Looking great though!

Thanks. In a normal world like the one in the video there are about < 600000 textured faces (51 of 32x32x128 blocks sectors are visible). But the more difficult thing to solve is to keep the amount of objects (geometries) low while at the same time allowing to modify the object's mesh within a reasonable time.

And yes, as you already noticed there are not only cubic shapes possible: I also added the possibility to use cusom meshes (from blender). They are also tesselated to one big shape per stripe but overlaping faces are not removed due to the immense amount of permutations needed to determine what block with what other block would have what faces removed (but still I also think about possible solutions for that). Meanwhile I plan to limit the objects with custom meshes that the player can place by natural factors like the items that are needed to replicate (=craft) them.

Been following the thread for a while now but never really posted.I just have a question, what method do you use for the SSAO? An SSAO shader of some sort or do you just edit the vertex color based on surrounding blocks?Thanks, and good luck

I don't use SSAO as it only takes in account the visible geometry (= screen space). The problem with that is, that while it might look good on the surface, it will look unrealistic within caves as they should be totally dark most of the time but they wouldn't be with SSAO.

So what I actually do is I have a 3D texture of light values (I call it a LightDistributionMap) that are computed when the sector is constructed. Basically all light flows down from the top (from the sun) and is then smeared along the x/z-axis. So in the shader I just use the LightDistributionMap texture and calculate my lighting by using the normals of the surface and get the light value where these normals point at. And using more than one sample interpolated gets me this quite smooth look of the blocks But still the calulcation of these LightDistributionMaps takes quite some time (around 600ms per sector) so that I might still have to change a few things ...

I love the style you've started here. I'm curious since I just started playing around with cubic frameworks in JME3. How many verts/tris are you rendering textured at once? Do you import models of the blocks, assume their structure is all cubic or do you have other shapes too? (I thought I saw some slanties in there).

Looking great though!

Thanks. In a normal world like the one in the video there are about < 600000 textured faces (51 of 32x32x128 blocks sectors are visible). But the more difficult thing to solve is to keep the amount of objects (geometries) low while at the same time allowing to modify the object's mesh within a reasonable time.

And yes, as you already noticed there are not only cubic shapes possible: I also added the possibility to use cusom meshes (from blender). They are also tesselated to one big shape per stripe but overlaping faces are not removed due to the immense amount of permutations needed to determine what block with what other block would have what faces removed (but still I also think about possible solutions for that). Meanwhile I plan to limit the objects with custom meshes that the player can place by natural factors like the items that are needed to replicate (=craft) them.

Hey thanks! I was doing some testing and with a generic simplex noise method I have a 160x160x32 volume and it generates about 2million tris, it doesn't do any face merging, or tesselation, and it only allows for cubic geometry at the moment. But as you can imagine, 2million tris kicks the engine into around 40-60fps on my card. So the performance isn't necessarily awesome. I need to do some more reasonable terrain gen to see if it's better as right now it's pretty close to checkerboarding so I may be seeing the worst case scenario.

Interesting, I never thought of it that way thanks for sharing! If it isn't a hastle would you mind uploading a LightDistributionMap texture somewhere?

I just saved and linearized it to a 2D image (because as I said it's a 3D texture):

It stores the information only in the red chanel of the texture (that's why it is all red). The white lines/numbers are not part of the original texture. The light map here is from one sector and each slice shows the x/y-information (mirrored along the x axis, because the y axis points down in images, but up in OpenGL), the white number gives the according z position within the sector. A sector has 32x128x32 blocks.

Heh, sorry I typed that when I was in the pub and I actually meant "insert name"craft that you see everywhere.

I think minecraft is a piece of art. I do however have a mixed view on minecrafts progress over the years, just seems like notch should work of refactoring and getting a proper mod api (which I think is happening now).

This game looks good, it is unique. Keep at it.

Sorry for my abstract , misleading and vague replies.

"This code works flawlessly first time and exactly how I wanted it"Said no programmer ever

Notch doesn't work on the game anymore and considering the dev team is only a few strong, I think they are doing a fine job. Can you even imagine how hard it would be to make a mod API that works very well?

Notch doesn't work on the game anymore and considering the dev team is only a few strong, I think they are doing a fine job. Can you even imagine how hard it would be to make a mod API that works very well?

Well yeah nothing is easy but also not impossible, the community managed to make one that sort of works. They are doing OK but IMO, it feels like nothing ever gets added to the game that makes it feel fresh, mostly internal code changes that is not immediately visible to the player.

I've not checked on it in the past year mind you.

"This code works flawlessly first time and exactly how I wanted it"Said no programmer ever

A few people vs. Thousands of developers in the community. Yeah, that's a fair comparison.

If you haven't checked the game out in a while then it's not fair to criticize the developers who are working hard adding new features in often. The last year has pretty much been all new features. Now, I'm not a Minecraft lover, but I give credit where it is due, and the Mojang team is definitely doing good.

First things first: I decided to release the game in alpha state on 1st of October 2014 (give or take a few days). It will be released on Xcylin's website which (hopefully) will be finished until then: xcylin.com.

In the last couple of weeks I did a lot of work under the hood to prevent jittering and lagging. I found (after a lot of bug hunting) that the GC was responsible for it, when it did a full collection of the old gen space. After a lot of trial and error I came to the conclusion that my mesh builder was responsible for most of the GC's time. It uses an octree internally and that octree is built using simple Java objects with references to each other. Obviously the GC is not happy when I have a huge tree in memory that is no longer reachable as it needs to check every object and go through the whole tree to find that the object is no longer used. But I found a way around that by linearizing the tree into a buffer and keeping the objects at the tree's leaf in a simple collection. When the buffer is not used anymore, the GC can collect it in < 1 ms.

Next I wanted to make the drilling laser more realistic, and so it now induces energy into the blocks. This energy builds up until the block explodes. Here is a screenshot of how the energy build-up looks like in-game:

And here what it looks like when they explode with the new particle system I added:

As you know or might not know: in Xcylin you are stranded on the planet, because your starship crash landed on it. So I'm currently working on a special "world" where I can construct the wreck parts of the ship in-game and store them to disk, so that it can be placed randomly on the planet later. This "world" is called "construction world" and is a completely flat terrain where placeable parts can be built. Currently it looks like this:

That's it for now. I try to post more updates here on a regular basis. Stay tuned.

Okay, I know first of october was yesterday, but I keep it as the guys from Blizzard: "It's done when it's done". And there are a few things that need to be done before I can release it as alpha version.

But until now I added a lot of stuff and fixed a lot more stuff (also a very crucial jittering bug). For example I've been working on the world's topology and wrote a special explorer software for that:

in 3D this looks like this:

Also a lot of non visual stuff has been enhanced. For example, Xcylin is faster now than it ever was before. The sectors' meshes now also use an octree structure to handle their mesh information, making it rocket fast to change terrain. Also a lot of refactoring was done to make the code more maintainable in the future.

And I found a very talented composer, David Levy to compose music for Xcylin. Here is the first track that will be used for the trailer:

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org