Immortius

[Immortius]

• Name: Immortius
• From: Australia
• Skills / Tools: Software Engineer with fairly holistic experience, C, C++, Java, C#. Messed with a lot of different libraries - Raknet, Irrlicht, Ogre, some OpenGL, Unity, Unreal Engine. Have done networking code, game logic, stealth systems, saving/loading, some shader work, some AI, some procedural terrain generation.
• Found via: Google search for jbullet + voxel when researching for ideas on how best to implement better physics for the voxel game I was working on.
• Interests: Some interest in stealth gameplay, large interest in coop gameplay. Might be interesting to do something along the lines of players starting as primitives and working together to develop a civilisation.
• Extra:
  Some things I've worked on:
  - Nightblock is the voxel game I've been working on. Highlights are an entity system, a lighting system with shadow casting, and support for non-cube blocks (stairs, doors).
  - Sburb House Building simulation thing I did. Can detect when part of the house has become detatch and remove them. Can be tried here (Unity Player required)
  - AI Attack Demonstration
  - Spaceship game where you design your ship out of blocks and circuits. (requires Unity Player)
  - Spherical planet voxel world test (requires Unity Player)
  - Procedural terrain generator test (requires Unity Player)

 

[Cervator]

Welcome! Nice Youtube stuff, spiffy to see the Love references, that gamed looked strange but neat

The attack video in particular looked nifty, being that we'd like to see interactions like that with some of the terrain, in particular from creatures - creatures that themselves sometimes should be building their own civilization, that activity isn't necessarily limited to the players in Terasology

Any thoughts on an area you'd like to contribute to? Stealth gameplay is probably a ways out, civilization building closer, but we still need some fleshing out of the creature system for that.

 

[Immortius]

Any thoughts on an area you'd like to contribute to? Stealth gameplay is probably a ways out, civilization building closer, but we still need some fleshing out of the creature system for that.

Probably getting basic multiplayer going to start with, although the game is stuttering too much on my machine at the moment to tackle that. So maybe looking at improving chunk generation performance or metrics gathering or something similar first. And just getting familiar with the project.

Edit:

Some metrics, rolling average over 60 frames. Really need to add spike tracking though, and burrow deeper. Or maybe selectively target specific areas.

 

[Immortius]

Sometimes the calcSelectedBlock() method in Player seems to run away.

 

[begla]

Hey Immortius! Glad you are interested in contributing to our game here.

I had some quick-and-dirty profiling system in place a couple of commits ago – but I have removed it since I started to use "YourKit" for profiling. There are two things that come to my mind that might be fitting for you to get into the project:

1. Looking through the rendering architecture and giving me feedback where things could be better and especially faster. So your profiling approach is already a good start! Feel free to put your optimizations into place and have me a look at your personal fork.
2. Writing a exporter for custom block-meshes and making the whole chunk generation process a lot more modular than it is at the moment. Blender sounds like a perfect candidate. Currently I'm putting all vertices into the right places manually using some VBO factory classes. This also applies to the (un-optimized) weapons and tool meshes. There is even some weird stuff going on like transforming "default block vertices" to "lowered water block vertices" instead of two explicit vertex declarations.

Since I will start to work next week, I can not continue to work full-time on the project. So I would be happy if someone like you could look into this more complex and very important area of the game while I'll look into some advanced rendering effects like HDR rendering, depth of field effects and maybe some gameplay related stuff that I can divide into smaller pieces.

What do you think? :?:

 

[Immortius]

Sounds like a plan. I'll start with 1, and when I'm a bit more familiar with how things work at the moment proceed onto 2. I also need to spend a bit of time getting up to speed with Git and GitHub, I've primarily used Mercurial and SVN and the past.

 

[Cervator]

Count me in for the "Git is weird!" camp

The DevSetup page can be a good reference, at least, tho I'm sure it can be improved too! I've got some more notes to put on there soon after messing around with integration last night.

 

[Immortius]

Committed my metrics work and some optimizations to my fork.

The metrics take the form of 3 overlays that are toggled through with F4. The first screen shows the running means for the top 10 marked activites:

The second screen shows highest recent spikes, decaying over time.

With the spikes screen I noticed that the spiking seemed kind of random, so I figured that other threads were interrupting at various times and being charged to whatever activity was running, so I added a view of threads run during the current frame. This probably needs to be improved so it is easier to see what is going on, and some time cost information would be nice too.

Optimisations

I've made two changes in my fork that have alleviated the stuttering issue I was encountering somewhat:
* Set thread priorities. With the main thread set to max priority and all other threads set to minimum the frame rate was smoother for me, probably because background threads were more likely to be processed during Display.sync().
* 16 threads were being started each frame to update chunk rigid bodies, most of which would do little to no work as they'ld stop during three early checks - which also prevented them appearing in the active threads debug display. I changed it so the threads would only be created after those checks.

One thing that may be worth considering in the future is to switch from jbullet to native bullet. This will allow taking advantage of GPU acceleration when it comes in bullet 3.0.

 

[begla]

Great work! I'm currently working on some optimizations myself. I've completely removed occlusion culling and "sub-mesh" culling for time being since it only introduced overhead. I've tried 3-4 different approaches to make use of occlusion queries, but... With no usable results. I'm beginning to think that Java is becoming a real bottle neck here. Meshes can still be split into smaller meshes though because – might be useful for some heuristic optimizations later on. Liquids are now simulated at once and not gradually like before. All those concurrent updates were really nasty on older machines. Physics meshes are now correctly removed after some time because those orphaned meshes caused the chunk cache to continuously write chunks to disk and instantly load them again. :shock:

I'll take a look at your optimizations later on and – if your okay with it – i'll directly work them into the develop branch together with my HDR rendering part I'm working on.

 

[begla]

One thing that may be worth considering in the future is to switch from jbullet to native bullet. This will allow taking advantage of GPU acceleration when it comes in bullet 3.0.

Is this a separate project I do not know yet? I only know the native bullet implementation available in jME3 and that one is somehow too closely linked to all the JME specific stuff. Or are you thinking of writing a new wrapper?

 

[Immortius]

Is this a separate project I do not know yet? I only know the native bullet implementation available in jME3 and that one is somehow too closely linked to all the JME specific stuff. Or are you thinking of writing a new wrapper?

A new wrapper, I guess.

Liquids are now simulated at once and not gradually like before. All those concurrent updates were really nasty on older machines. Physics meshes are now correctly removed after some time because those orphaned meshes caused the chunk cache to continuously write chunks to disk and instantly load them again. :shock:

I suspect my machine counts as a borderline older machine - it's an early Core 2 Duo build, although the video card is pretty modern due to a failure-induced-upgrade. I plan to upgrade this year. I did notice the chunk cache issue - "Flush Chunk Cache" was continuosly appearing in the thread list and dropping my fps to ~35.

I'll take a look at your optimizations later on and – if your okay with it – i'll directly work them into the develop branch together with my HDR rendering part I'm working on.

I am happy with that.

 

[begla]

Okay! I've put your changes into the develop branch. Sadly your GitHub nickname became "unknown" in the commit history. Will look into that tomorrow. Still can't figure out why the game starts "peaking" so much after some playtime (especially if the chunk cache hit max). Maybe you'll have better luck?

 

[Immortius]

Okay! I've put your changes into the develop branch. Sadly your GitHub nickname became "unknown" in the commit history. Will look into that tomorrow. Still can't figure out why the game starts "peaking" so much after some playtime (especially if the chunk cache hit max). Maybe you'll have better luck?

Running about today with your branch, things seemed pretty smooth even when the cache maxed out. Still the occasional stutter but this was running full tilt in god mode.

One suggestion I have is that when the chunk cache max is hit, to flush to a level a bt below the maximum so that it doesn't linger at that level.

 

[Cervator]

I've seen that unknown thing too, I think from early small-jeeper commits. It looks to be related to local git config?

http://stackoverflow.com/questions/8283 ... or-unknown

 

[Immortius]

Ok, worked it out. Have been committing and pushing via Git GUI, and needed to set up the config in that.

 

[Immortius]

I have put together enough code now that shapes are being used in place of all the previously hardset mesh values during chunk generation. This includes the cactus

Liquids are a little awkward, as they use two shapes - one with a lowered bottom and the other without. But depending on how liquids will ultimately act they will probably be a special case anyway - don't know if you want to do a DF/Terraria style system or what?

Along the way I put together a special command handler for groovy console - the idea being to provide simple commands for things user may want to do, rather than having to know the code base (which won't necessarily work anyhow). At the moment it just has the one command:
cmd.giveBlock(id, quantity)

I still need to track down some other systems that could use this information, and then add support for shape rotation.

 

[Cervator]

Neat! Thanks

Liquids - really not sure yet, too technical for me to think up too many details. I'd like to see a more natural approach like DF/Terraria (you can't just pour a bucket in a spot and get infinite water only spreading 7 blocks out) - but those are both 2D and a fair bit less complicated to do liquids in

Also appreciate the extra command handling in the console - we used to have both, but needed to redo it exactly like that, with later also supporting multi-line, help text, etc

 

[begla]

Great! Can not wait to see it in action. More natural acting liquid be a long-term target but, as Cerv pointed out, this is going to be quite the challenge in R^3 – but me like challenges.

 

[Immortius]

New torch block(s):

Next I'm thinking of doing some more cleanup around the block loading, and getting stair collision working properly.

 

[Cervator]

Nice