Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - JackOatley

Pages: [1] 2 3 ... 49
Discussion / Re: Is Terrablox and it's community dead?
« on: January 30, 2018, 10:13:42 PM »
Hey guys.

I can't find my last post here but I did mention coming back in November, I think. I've been working on something else which I've only recently been getting useful feedback on. It's a web-based game creation tool. It's called GameBeans and you can check out the progress, and gets links to the tool, on Discord here:

At some point, I will be coming back to voxel stuff, but using GameBeans. As all my latest work has been in JavaScript, this will mostly be ported over to that. Specifically, what I'll be doing is creating a JS library of the voxel engine itself, opensource. And then using that to create a new Terrablox in GameBeans.

Honestly, though, I'm considering closing these forums. Even when they were active it was difficult to manage. Any of you that are still interested in the project, hunt me down on Discord, and we can find anew place once I get onto the project again.

Discussion / Re: Call me crazy!
« on: October 01, 2017, 02:36:01 PM »
Hey guys, or anyone who still checks here, lol! Been out the loop for a while due to jams, I even hosted one. Ya'll used to my priority shifting now, anyway, I imagine!

Anyway, this project is still going, I've learned a lot more using JavaScript and currently rewriting a lot of it to work with NPM and build systems on there like webpack. So basically converting it from hackky fake modules to actual ES6 standard modules, which are currently not supported in any browsers (except maybe Opera), thus need transpiling through build systems. But, that's how I'm making my jam games these days and it's a great move towards making this open source.

Current problem after coming back to it after a while; suddenly the directional lighting is really laggy. Not sure why, either newer GFX card drivers are being weird or maybe I need to update my browsers again. I don't think it's my faults, haha, nothing in the code has changed afaik!

I'm working on something else as well currently. But in a couple weeks when that goes closed alpha, I'll be sharing time with Terrablox again. I'll post here occasionally, but otherwise you'll see my activity jump up on Twitter. :)

Discussion / Re: Call me crazy!
« on: May 30, 2017, 12:35:20 AM »
I've been working a lot with getting all these little graphical features working well together. Despite still not being able to set a minimum mipmap LOD, I got it working together with tile borders which can be used to somewhat alleviate the issue.

I also set antialising on, which helps create a smooth image at 1:1. Previously, to get a smooth image I've been drawing at double res then scaling down (SSAA, on a browser this is as simple as zooming out the page).

The blue speckles on the mountain are due to the same mipmap LOD issue... When using the borders, the final image may not be a power of 2, so it has to be resized and currently the areas of the image not filled by the actual texture are blank and these get blended into the smaller mipmaps.

And forgive the seams you can see on the mountain too, they are temporary. They are due to me doing the Vertex-AO in the mesh thread, so only voxels visible inside that chunk are available to check against. This will be changed so the VAO is done in the culling thread and those edge voxels will be present.


Fixed those previous issues. I now fill in any empty space on the final texture, it's also optimal (depending on how many tiles there are) to use half the tile width as the border, as this perfectly fills out into a power of 2. There was still an issue where deliberate alpha, such as that on the leaves, was also bleeding into smaller mipmaps, I now resole this by "overdrawing" the tiles on lower mipmaps, this gradually makes the tiles become fully opaque, as you can see here:

As you can see, leaves further away become a solid color. Another thing that fixes some of the mipmap issues is anistropic filtering, which determines how many samples are taken to work out which color to use on screen from various mipmaps, this certainly fixed the brown tree tops, as it's reading in more greens from the bigger mipmaps.

Anyway, over than tidying up, I think I'm done with that graphical stuff. :)

Discussion / Re: Call me crazy!
« on: May 25, 2017, 01:20:00 AM »
I started implementing the block index, so the engine can now actually have multiple textures over a single block. I'm thinking of changing it from what I had before though, so instead of referencing the index number of the texture to use, it could instead reference the name (as textures are single files now).

I also got transparent textures working, as usual it's only opaque and completely transparent.

I think it looks really good now, but I definitely need to do something with the sky and water to really finish off these still scenes. Those things look way too flat now.

It's also worth nothing that I haven't even started with custom shaders. I'm thinking I will have to eventually, there's things that don't quite make much sense how they are right now, for example: three.js uses 32 bit floats to represent a single color channel when using buffer geometry (this holds a value from 0 - 1), you can put data into a 8 bit uInt and it won't error but the default shader doesn't seem to recognize the (correct) 0 - 255 data. When I do though, I won't make the mistake I made last time with over-optimizing, cramming all that data bitwise into the various vertex data ultimately made it un-portable.

I got manually created mip-maps working, when I say manually, it's still automatic, but done by the engine now and not by three.js/WebGL. This yields better results but there's still issues. There doesn't seem to be a way, at least that I can find, to set the minimum LOD for mip-mapping. So you're forced to use mip-maps all the way down to 1x1. Which is far from ideal when using a texture atlas. For example; my atlas currently has 4 x 4 textures on it, now if the size of the mipmap is 2x2 or 1x1 then tiles start getting blended together, resulting in the wrong colors on screen when it uses those mip levels. As seen in the brown tree tops and green sand in this image:

That's the only issue with mip-mapping left. So I'll keep looking because it seems like something that should be simple to change.

Discussion / Re: Call me crazy!
« on: May 24, 2017, 01:44:26 PM »
I added per-vertex ambient occlusion last night, managed to do it with little speed impact as well. Though it's currently done "live" in the meshing thread, where really I want it included in the voxel prefab so I never have to calculate it again, merely pick it out with a bitmask. And the bitmask should be calculated in the culling thread, probably combined with the culling mask (as that can also be used for AO).

Anyway, pics, notice the trees, they benefit the most from the AO, giving them nice dark hidden areas:

Discussion / Re: Call me crazy!
« on: May 16, 2017, 07:48:59 PM »
I put voxel editing in, it's now also a breeze to plot models as well. There's still some chunk-border issues, as always. And there's an issue with trying to edit a chunk while it's voxel buffer is currently held in another thread, it doesn't wait for it yet. Oh and there's a memory leak somewhere. But otherwise it's going well!

Discussion / Re: Call me crazy!
« on: May 13, 2017, 12:56:44 AM »
I slowed down a bit there. Just my regular depressive slump lol.

I've been mostly working on tidying up the engine and modularizing (I think I made that word up) it. To this end I also started working on a separate web app just for the heightmap thing as I suggested before on my blog, it directly uses the height map class and methods from the engine so when either project evolves, so does that source.

I'll talk more about the height map app soon as it's functionally complete and the UI is pretty much done. Just a few buttons need text and some non-core features. But for any of you working on projects involving height maps it'll be pretty useful for creating unique maps from generated or imported images.

As for the engine, I've set it up now to allow specular, bump and normal maps. You can't use bump and normal maps together, but they give different effects. I plan on setting it up so you no longer have to edit the textures as a whole sheet, they'll be individual textures in sorted folders and the engine will handle stitching them together. The goal of that is to make the different maps optional per texture, and possibly allow custom mipmap textures. Mipmapping is already automatic but currently suffers from texture bleeding if used, so the stitching will be able to fix that anyway without custom maps.

Today I added in most of the old Terrablox tree models, the only thing that needed to change was changing the string names like "leaves" to the actual index number. Anyway, here's a quick pic:

Also, I got a 1,000,000,000+ (2048*2048*256) (billion) voxel world running. It's very hard to get a good result when you hit that 256 height mark when using a height map, as that's it's max fidelity. So I'll have to come up with a way to increase detail using the Heightmap class, rather than effecting the images.

Got the texture loading from individual tiles today, which is handy. It's also able to build and display the world before any of the textures have finished loading, and it should be able to update the texture on loading of each individual tile... Which isn't massively helpful, but is interesting, it would mean even if you have large textures with normal maps, specular maps, etc that it wouldn't incur any loading time, it's all asynchronous.

Also added basic beach/shore detection and fixed the tree generation (it previously only spawned trees on slopes facing a certain way), this was due to me forgetting I have a 1 voxel border on all 6 sides of a chunk now, so I was forgetting the "up" offset:

And here's a sample screen of the Heightmap Creator app I mentioned, I wasn't able to actually do anything on it today, though. I've got a lot of cool ideas for this though, it'll be a cool tool. :)

Discussion / Re: Call me crazy!
« on: April 30, 2017, 06:37:13 PM »
I dont understand how youre doing all this so fast but all i know is i want to do it too  ;D ;D ;D
Spoiler (hover to show)

Discussion / Re: Call me crazy!
« on: April 25, 2017, 07:05:36 PM »
This looks so epic...good god even tho ive seen most of this stuff before hand still !!! That water plane scene just killed my soul.
To be fair I do use that MSAA hack I mentioned to ya when taking these nice shots. Softens up all those edges and reduces distance noise. :)

I haven't done too much today. We otherwise have some free time here yesterday and today and a bit of tomorrow so I've been decorating! I did do something cool though. Right, well, this engine has 2 UI/HUD layers, one of them is a drawn one inside the renderer (currently has the crosshair), the other is a HTML one (like the fps counter and now the console). So the console is the main thing here, JS can execute code from a string so I thought I'd put that in quickly as A DEV TOOL (you wouldn't release wit full JS execution), so if there's something I want to try and don't want to go into the source to mangle some test code in, I can run it from this console. Check it out:

I put this on Twitter last night because someone was curious as to how fast this generates chunks:

This is in real-time, you can move around smoothly while that generation is happening. But there is still a delay at the start where it reads the heightmap (fast) and places the voxels in the chunks (slow) and even a delay sending that data to the culling worker (slow, not sure why but probably because of large amounts of data to be copied). Each chunk is processed based on the order they are sent to the culling worker, hence the row-pattern. Meshing is almost instant, 15 times faster than culling, so it's culling thats making this pattern actually visible, because it won't process the next chunk until the current one is finished and has been sent back to the main thread.

I'm not sure if this is faster then the Windows TB yet, that initial startup certainly isn't. But I still have optimizations for the culling, as it currently iterates ALL voxel space... TB actually skips 95% of hidden voxels and thin air, so I'm going to use that same optimization method in this.

OK, compare this to the gif above and that's how much faster it is, about 2 - 3 times faster. It's difficult to get an accurate measurement in a browser and when using multi-threading.

The total time it used to take to finish creating the whole map (256 x 256 x 32) was 6.5 seconds. Now it clocks in at around 2 seconds. I spent a lot of time tweaking my process, which included optimizations that worked really well in GM, but it made no noticeable difference.
The actual problem turned out to be the data. When I was sending the voxel map of a chunk to the web worker it had to copy it, a voxel map has the structure [array][array][array]{object} which turns out to be pretty big. I now convert this before sending it to the worker, so now it's an ArrayBuffer with a linear list of entries in the pattern of [x, y, x, texture, cullingmask], which is allowed as a "transferable object", meaning when I post it to the web worker I can list it as a transfer and only the reference will be passed, it clears the data in the main thread and hands it to the web worker with no copying, instantly faster.

I'll be starting to write on my blog again soon with these updates. Because I want to explain so much and this doesn't really seem the best place to do it. Anyway, I'll still put some "exclusive" stuff up here occasionally. :)

In just the last day the engine has come on leaps and bounds. It can now generate even huge maps in a second. I even loaded in a 1024 x 1024 x 64 height map of Denmark. There's still some startup delay as it reads the heightmap and populates the chunks (though I will be fixing this soon), but the culling and meshing still take around a second in total, it's mindbogglingly fast, I'm still surprised how much faster than even GM YYC builds of TB.

Some other things I added are "side rendering", where if it's a finite map it'll draw the sides of the world. And I've improved the shadow mapping, it's now more focused and it follows the camera around to try and get the best shadows possible for the local area; it's not cascading shadow maps as three.js doesn't fully supported that (through lack of maintenance. ie, nobody is really using that feature). Anyway, here's a pic:

Discussion / Re: Call me crazy!
« on: April 22, 2017, 07:10:22 PM »
This is freaking crazy! I didn't know you were so adept at JavaScript! It makes me want to learn it.
You should, JS is awesome and a very important language to know. :)

I started learning it ages ago when I was first messing around with websites. And I've made lots of little game engines for my own amusement since HTML5 came about. But it was only recently I decided to finish something with it. And so this is just a culmination of steps.

Anyway, most of the visual stufs right now is handled by Three.js, like the rendering, shading and shadows. But the voxel engine and the system around it, and now even the meshing, is all my code.

I got textures working now, well "A" texture. Though it should be simple enough to use multiple textures like before, just offset the uv by whatever the voxel needs. There's also mip-mapping here (again, three.js just has that as part of the material object). Also, got Input and Camera classes set up. So the world is navigate-able now:

OK, so multiple textures are working now. Although WebGL orders it's UV from the bottom-left as opposed to GMs upper-left, so that was confusing for a bit. But really all it means is that I have to index the tiles a different way round. For this image I also added in a sky-colored background and some fog, just makes the whole thing come together nicely:

I got delta time sorted out today. I wasn't going to bother for a while but it seems a weird thing happens due to v-sync. Chrome can switch from 60fps to 30fps arbitrarily. From what I've read this is a v-sync issue where Chrome would rather sacrifice frame count for frame quality. It's not a big issue but it was annoying moving around with the camera and full or half speed intermittently.

I also started working on culling. The actual culling doesn't seem to take any time at all, JS (Chrome at least) seems to handle arrays uber fast and that's all the culling requires atm, array lookups. I haven't actually timed it yet but it's not making a dent in FPS. However, with voxel faces culled and a new "visible voxels" object being passed to the meshing worker, the meshing itself is around 15-40 TIMES faster, now clocking in at about 0ms - 4ms a chunk. If you consider that a single frame at 60fps is 16ms, this is well within bounds to do in even the main thread. So it's should be OK when it comes to more complex geometry. :) I'm not handling the edges just yet but here's a picture of my work in progress:

Culling is now in. Handling the edge cases did slow it down a bit, although I do do it all at once, but I was planning on doing it in a thread anyway, to handle future complexity. Nor did I spend long trying to come up with a genius way of doing it, but it's still better than before. The GM Terrablox actually has the culling and meshing in the same place. Here it's 2 separate things. The meshing is the fast bit, it deals with everything it's given without caring what it is. The culling is the slow bit, but this only needs to be done when the chunk is first generated. Later culling operations only need to cover changed areas.

I added a water plane as well:

Discussion / Re: Call me crazy!
« on: April 21, 2017, 11:52:24 PM »
I've changed the height-map system into a class. This means you can load a height-map and do loads of things to it before passing it as a single object to the world. So create a whole world from an image currently looks like this:
Code: [Select]
var world = new World();
    new Heightmap( "img/hm2.png" )

I'm working on the camera and movement, so I can ditch that orbital camera and actually navigate around the world. This will help when I come to implementing the face culling so I can see it actually working. I can do culling in another thread so as not to distrupt the game, I reckon when this is all done it'll be a very fast little engine! :p

Here's a cool render:

I'm not sure yet how that phong shading will work with different textures/surfaces, seeing as a whole chunk shares a material. Though I think you can add secular maps. I'm not too familiar with all these lighting/shading things, so we'll see!

Discussion / Re: Call me crazy!
« on: April 19, 2017, 02:33:41 PM »
Your crazy, but I really do like the idea of this though i'm not entirely sure how far you can go with JavaScript.
It's going to take a bit of effort to get a 3d application running smoothly, but I will get it there.

Three.js is decent for rendering, but I've already been working around some of it's built in functions for dealing with geometry. I got it to send just the vertex data between the main thread and the worker thread, so no more string converting. But that wasn't completely the issue anyway, the issue was trying to run too many workers at once, they all ate into each other which had a knock-on effect in the main thread when all the callbacks came in at once. But I build the vertex buffers manually now which is both faster and more memory efficient and takes <30ms for basic chunks (remember I'm not culling atm, so this could be better). So here's a pic of the obvious improvement since yesterday. :)

Those with slower connections are going to hate me for all these gifs. :) I got normals data going as well now. All data is currently derived from a single cube model so this doesn't need to be calculated or anything, it just needs to be compiled into an array a handful-tens-of-thousand times (like I said, no optimizations yet!).

And here's a wire-frame view to show how unoptimized it currently is. I think it's doing things rather quickly considering the amount of unnecessary vertices in there.

Today I took three.js out of the web worker file. Web workers can load in other js files to access their functions, to do this however they don't get it from cache so have to recompile that file. This was to the tune of 300ms. All I was using it for in the end was the cube model, so I now construct this manually and lose that 300ms waste.

This is the box model:
Spoiler (hover to show)

This tiny model can be used to represent all voxel configurations. The idea being that you can selectively pick the faces to use per voxel when building a mesh.

There's still some lag/delay if I set it to run all the workers at once, but this may be because there's supposedly (I read) a 30ms-ish delay when setting up a web worker. And seeing as each chunk creates it own worker, and there's 8x8 chunks this comes to nearly 2 seconds, which seems to be the startup delay I get. I am planning on adding a proper manager/queue though, so there's just one worker to handle all chunks.

Anyway, enough tech stuff, here's a gif showing the normals working with three.js lighting with a shading material on the mesh. Forgive the jerkyness, that only happens when I'm capturing the gif. >.<

I just wanted to get this working to make sure the current mesh setup allows it. Shadow maps aren't very well documented or they don't work quite as they should. I only found out the bit I was missing from a bug report from 2012. All I was trying to do was move the shadow map camera, or where it looked at at least, turns out it has to look at another object and that object has to be put in the scene, confusing. But I got the result I wanted eventually:

Definitely need to get some height-map terrain in here!

OK, terrain is in:

I also got memory usage down A LOT by directly writing into the vertex/normal buffers rather than filling up an array and then converting it to a buffer. Using arrays, even temporarily, too much seems to send memory up quickly. It does go down after a while when the garbage collection catches up, but on the amount of data that gets shifted in this kind of game it's not really workable to use arrays in some places.

Discussion / Call me crazy!
« on: April 18, 2017, 04:30:37 PM »
This may be crazy, but I'm remaking Terrablox again!
OK, put down the pitchforks and torches. I have lots of reasons.
So read through and let me know your thoughts. :)

Current Version:
I will likely be coming back to the current version to get it into a game/playable state. But it's going to be difficult to ever evolve it too much. And the time I can spend on it is very limited as it doesn't, and probably won't, generate money. So I have to concentrate on things that do. It also won't port to GMS2, the shaders are over-complex, which is my mistake, yes they are cool and fast but then YYG took out DX9 support and screwed them all over, and their support to DX11 was broken for so long and there's still issues. And even if it did port, the new IDE does not lend itself well to it's current structure.

The Hate:
On top of those issues, I'm finding GM just toxic these days. I no longer have belief in it. The experience of using GM is a bumpy road, from something always being broken, to fixes breaking other things, to rubbish/incorrect documentation, to the only decent reference material (the old GMC) vanishing from the internet (can't google it). I just got fed up.

The Solution:
Anyway, enough of the rant. I have a new plan. So I entered a game jam recently, and for it I decided to use pure Javascript, using HTML5 canvas for rendering. Now I was already familiar with JS, but I hadn't actually made and released a full game with it before. So I did and it went really well and was enjoyable. So for the sort of games I usually make, 2D pixel art stuff, I'm more comfortable with that now. But what about my 3d stuff? I only really have Terrablox. So, can I make that with pure Javascript?

The Attempt:
OK, so I have already set up a project and have things actually working. I'm using the Three.js library for all the 3d stuff at the moment, it's quick to set up and do stuff with and will demonstrate viability sooner. It manages things like the renderer, scene, camera, geometry, etc. Voxels are now objects, so they can have all the properties they need, rather than just being a single value. It has multi-threading using web workers, currently I have this building the mesh. Web workers are tricky as you can only transfer object data as strings, so string>object conversion still happens in the main thread.

Despite Javascript not having any "include" command by default, it does lend itself well to being modular. So this project will also be open source. That way I finally keep that promise, and can easily keep any game (art, audio, game logic, etc) separate from the engine. Not being able to easily separate engine and game before was the reason it didn't happen.

I have not much to show atm, currently there is a chunk that can fill up with voxels, and then build a mesh in a separate thread, and then return it, and finally add it to the scene. My next goal is to have the world object load in a bitmap (heightmap), create chunks and generate voxels based on the world heightmap data. There's also currently no culling or any optimizations. I'm still in the viability stage. So don't get too exicted. You'll see it when I get it looking like something. :)

So to recap, I know these are things that have been requested before:
  • Open Source
  • Multi-threading

Spoiler (hover to show)

Discussion / Re: What's been happening
« on: February 07, 2017, 01:50:11 PM »
On a Terrablox note though...

I've still been trying to port it to GM2. Apparently the fact that I couldn't get HLSL 11 Shaders working before is because they were broken in GM. They are now working, but not with my HLSL9 shaders. I can port the shaders to GLSL ES and HLSL 11, no errors or crashing, they just don't show anything... These shaders are pretty complex maths wise, as they have to get numbers from certain bits with no bitwise operators, so it's very possible that the maths is getting screwed differently than HLSL 9. I've no idea.

The only solution I can think of, that isn't me just running around in circles going "I got it, I got it!... Oh wait no I haven't..." is to go several steps back and get rid of the memory saving vertex format in favour of something simpler, maybe also remove some graphical features... And then try to work it all back in.

So, sorry for the delay. Blame YYG for removing HLSL 9 without any prior warning. And replacing it with HLSL 11 that didn't work. And on top of my other work. >.<

Discussion / What's been happening
« on: January 20, 2017, 10:47:48 AM »
So before anyone starts proclaiming the Terrablox End Of Days again, I thought I'd let you know what's been happening and the reason for a lack of updates in the last couple months.

Obviously, I was very busy over Christmas with family things. We've been painting/decorating/cleaning/fixing the house a lot too, it's something we have to do sooner rather than later. I'm helping Dadio on his big project, though he's been just as busy with his family as well. Also will be starting work on an update for an android game me and Dadio worked on ages ago as it picked up in December for some reason and is generating decent money (if we can keep the trend steady). I'm also re-working my websites from scratch (especially my wordpress blog, that's basically done though), and this may later include the main Terrablox site (finally, lol). I've also been working on a web game, it's an old-skool text-based strategy game inspired by one I used to play in 2004 (which no longer exists in any form, it seems), it's user/database driven (it doesn't have a persistent server, but it does catch-up time and game ticks are on the back of client updates, so it emulates a persistent server), the bulk of which is also done.

So I've got a lot of little things on the go atm. Some are opportunistic, so it's better to do them now then any later. Once I've dealt with them, then you'll start seeing Terrablox updates again. Terrablox, I feel, is very close to a well rounded state, so I'm eager to get back to it! :)

Pages: [1] 2 3 ... 49