Textures, blocks, and Groovy, oh my!

[begla]

Looking into this problem is the next thing on my to-do list. This might get quite complex because some of the coordinates of the block textures are hardcoded in the chunk shader. This is for example used for the waving grass and moving water surface, for masking grass blocks for biome coloring and so on and so on. Not quite sure yet how to implement this dynamic behavior since the amount of values that can be passed to the shader is quite limited depending on the GPU and OpenGL environment. :?

Just finished version 3.0 of the terrain generation algorithm which is quite the improvement in my opinion. All the changes I've made are mainly based on a new kind of preview algorithm I've wrote to easily visualize the output of the terrain generator (including volumetric data). I've used those previews to optimize the size of the terrain so it is actually fun to play with enough free space to move around while keeping the terrain structure interesting and memorable. The result of the 3.0 algorithm are landscapes with rivers, small island and continents. I've attached three images showing the same area scaled by two, eight and 32 blocks per pixel. The pixels are slightly colored according to the active biome at that point. The brighter the color the higher the terrain. I'll write a more detailed article on this new version (if I find the time ).

Also watch out for the player's hand I've just integrated into develop. *poke*

 

[Cervator]

This might get quite complex because some of the coordinates of the block textures are hardcoded in the chunk shader. This is for example used for the waving grass and moving water surface, for masking grass blocks for biome coloring and so on and so on. Not quite sure yet how to implement this dynamic behavior since the amount of values that can be passed to the shader is quite limited depending on the GPU and OpenGL environment. :?

Ooohhh. I was hoping the "0x0" and "(byte) 0" instances for empty/air were the only hard coded bits. I saw the color offset on leaves and that fit into the new system fine. But I'm clueless when it comes to shaders

Like hard coding Air we could do a few more very central blocks with hard coded IDs too. Dynamic IDs are mostly to make it easier to add stuff and tweak content (plants, trees, furniture, minerals, etc)

Terrain gen looks good! I'll have to check that and the hand out sometime. Need to find me some lava sights too

 

[begla]

Blocks can be poked now and need some time to actually pop into pieces. Small prototype for actually harnessing the full power of your forthcoming block type/metadata loading mechanism. Good night!

 

[begla]

Pushed another (big) update before I start looking into your new mechanism Rasmus! Feedback is appreciated. :twisted: Attached two (secret) screenshots... More details can be found in the commit message.

EDIT: Make sure to view the full images since one of the new features is cut off!

 

[Cervator]

:shock:

Game development certainly goes by leaps and bounds! Wasn't expecting to see some of that stuff for a while

That's one good thing about going to NYC on Friday till just past New Year's - I should have plenty of time to really catch up with some of this other stuff. Assuming my laptop can handle it, anyway

Nice screenies, can't wait to put the toolbar to use on something. They're not very secret in a public forum tho

I'm working on an architecture page in the wiki on the Block system - should be handy

 

[begla]

Putting all that stuff into the develop branch is not very secret either.

 

[Cervator]

Not a code item here (I'm at work) but I finished the first draft of an architecture doc page on the block system and its potential expansions

http://wiki.movingblocks.net/Main/BlockArchitecture

I suspect I might be too wordy (my thoroughness is both a blessing and a curse), but I tried to avoid situations where the documentation is likely to go out of date as we develop the code further - excepting the use cases and the meta block extension that might be my next big project

When the groovy blocks branch is fully functional and a little more published I'll make some announcements on it including links to the wiki doc for more feedback and for potential contributors to review - I think we need a few pages like this to help get new developers introduced more to the code.

 

[begla]

Nice! Very well written and easy to understand.

I've started looking into integrating the new "loading technique" and this forced me to start thinking about performance again... So I've added a small profiling class to the project and implemented a pie chart for easy visualization of the percentage of time that is claimed by important processes (chunk rendering vs. the amount of time spent calculating collisions for mobs for example) during one render loop iteration. The chart is still missing a legend though to make it actually readable and I'll have to extend the profiler to work with all the different threads used for generating chunks.

This made me re-optimize different parts of the engine again including some of the terrain generation stuff. The new starting area looks quite impressive in my opinion and it makes quite the showcase for the new terrain generation algorithm. Lava floating out of caves in small mountains and all that good stuff.

I've got some free time to spend the next few weeks and I'll use this time to get the "loading technique" ready with a greater focus on gameplay related stuff. Thinking of inventory, droppable items and...

 

[begla]

Just pushed some fixes to the Nanoware repository to make this beauty (somehow) work. Some fixes are still hardcoded just because I did not want to fiddle with your architecture too much. Here's a list of the issues I've found and what has to be done:

• Block coordinates are wrong and still for the old 16x16 texture atlas – the current fix is hardcoded and has to be replaced with dynamic values based on the width/height of the atlas (see next issue)
• The texture atlas should have length and height values power of two (otherwise calculations might be horribly wrong on some GPUs – like mine ) – the fix is hardcoded and sets the atlas to a fixed width of 1024. The width/height has to be adjusted according the space actually needed for textures (1024, 2048 and so on – free spaces can not be avoided though)
• PNGs are missing alpha information - fixed this for the leaf block to make sure
• The the "dynamic atlas" was created using RGB instead of ARGB information – fixed

I would love to put this thing into action. So... Would you mind rebasing this on top of our develop branch? All those old quirks with the physics stuff drive me mad. I'll need only a few more additional tweaks to make it work perfectly. I need some fixed texture coordinates for some blocks to do the "special effects stuff" in the shaders. This applies to the following blocks and block types:

• Water and lava (used to dynamically switch to the "animated texture atlas" in the shader and to create waves)
• Grass and this small grass mask (this is used to color the grassy segment not the dirt segment based on the currenty humidity and temperature - I'll create a separate atlas for stuff like the grass mask and the animated "block-damage-overlay" because they do not fit into dynamic block atlas)
• All flora blocks that should be affected by wind (high grasses, flowers, ...)

 

[begla]

Thinking of... I'll need the texture offset per block texture in the shader. This can be calculated by 1.0/(AtlasWidth/16.0). I don't like the idea of this value being passed to the shader all the time. Just increasing the texture width instead using an actual texture grid is not a too good idea either performance wise.

A better solution would be static a atlas grid with a fixed size of 512x512 pixel. This would result in an total amount of 1024 possible block textures (which should be enough in all cases).

EDIT: I might start integrating this whole thing into develop myself when I'm back home. So please don't start working on anything without getting back to me.

 

[Cervator]

Heya - sounds good with fixes and more info. I'm leaving for the airport later today so won't be able to catch up for just a bit. After I stabilize in NYC I'll try to get set back up for development so I can help out from there

The one tricky thing I foresee is if we have to hard code wavy plants - water and lava is pretty basic, but custom plants could be produced left and right by power users, thus the desire for those to retain dynamic textures. Any other strategies we can employ there?

RGB vs RGBA I had tried locally, but maybe loading in an image in the wrong format overwrote what I set in the constructor for the new image? Anyway, I figured it would be something not too crazy complicated. I'm sure there's a way to sort out the remaining few things out

Next big thing on my list is the MetaBlock concept. That should help with stuff like containers in the world that can hold stuff, and trees that know which blocks they're made up by.

 

[begla]

Merry Christmas!

I've got everything working using your approach Rasmus and just pushed my results. Even waving grass blocks can be defined as easy as "waving = true". Added some more features to the whole thing like auto-generated mipmaps. I only had to move the Groovy classes and the block images out of the .jar-file. Otherwise all the directory reading stuff led to really annoying problems. The block classes are now parsed using a simple GroovyClassLoader on-the-fly.

Added some more fun stuff to the game (like double-space-tap-godmode) and correctly colored blocks in the hand of the player. Those are now even influenced by light now relatively to the current player position.

So but now... Time to eat! Hope you're enjoying your trip to NYC.

 

[Cervator]

Bump! Bit of a pause working on this, but back in shape. Although now my nanoware/groovyblocks branch is hopelessly outdated

To keep things simple I went back to work on this old branch to figure out the jar file dynamic loading issue and it looks like it works now either running straight from source or out of a jar file.

I'm going to review it some more tomorrow and then cross-check with the current branch where all sorts of stuff has been moved around. Probably will need to manually do everything over and move stuff back around again assuming it works fully now, so that may take a little bit

The big question now is whether this still holds true if loading as an applet as the sneaky jar trick involves scanning the whole jar file itself - unsure if that is problematic if executing from within a browser....

https://github.com/Nanoware/Blockmania/ ... oovyblocks

Incidentally this still does not inject the non-Block Groovy bits into the jar file (config, etc), so actually it definitely won't work as an applet yet. I tweaked Ant and test-ran the jar out of the artifacts dir where the extra Groovy dirs still get copied to. So yeah, little more work tomorrow.

 

[begla]

Sounds good! Actually scanning the whole .jar-file was the part where I decided to move the files out of the .jar-file for the time being. Hm. Sad that there is no easy solution without too much code that needs testing on our side.

 

[Cervator]

Since it only happens once on startup I'm not too concerned about any sort of performance hit, I'm more worried if the more restrictive security context of running as an applet will block that entirely.

At this point I'll admit the obstacles are getting annoying and taking some of the shiny off the crazy architecture

It was meant to be super easy and take no added effort from the user, but if we have to go through so many hoops... blah. Considering if a build step to generate a simple list of stuff to instantiate instead would work, but that's just more quirkiness.

Anyway - I'll be tinkering with it more today and will see where it goes.

 

[begla]

Anyway - I'll be tinkering with it more today and will see where it goes.

Roger that!