(September 2016) Monthly WIP screenshot thread

Oh right, you pledged directly, so you aren’t in the mailing list. I’ll send you a pm with the links.

1 Like

Haha :smiley:


And the other side :stuck_out_tongue:


You might want to try Fedora or something that’s using Linux kernel 4.5+. I think AMDGPU was added to the kernel in version 4.5, might offer some performance improvements.


Also added in 4.5 is PowerPlay which finally allows Linux to take advantage of the power scaling abilities of newer AMD graphics cards. Previously Linux systems were confined to the lowest power settings on these cards, but with PowerPlay enabled Linux can now scale between the minimum and maximum power requirements as intended by the card manufacturers. PowerPlay is not enabled by default in the latest kernels.

Unfortunately I can’t try it out myself, my card is too old to be supported.


Haha, I love the poster!

“Higher top speed than Space Engineers!” (Not very fast at all…)
“Earlier release date than Star Citizen!” (Okay that shouldn’t be difficult either…)
“More realism than Kerbal Space Program!” (Could be a bad thing.)

Yes, I’m having too much fun thinking these up…



Now the voxelization opened a neat window into optimization of physics collision shapes. The ships use a compound collision shape composed of boxes which used to be numerous, one for each module.

Now I’ve used the priorly showcased map to calculate the largest possible volumes inside the ship every time it’s updated and reduced the physics load when colliding to oh so little.

Sure, it’s not exactly perfect but it’s as good as it gets in 0-1 milisecond.

And the framerate difference when colliding…

I’m sure that more than half of you are shaking your head at me for not doing this a long time ago. :sweat_smile: I would, I would if I knew how to. :stuck_out_tongue: Took me a while to figure out the process and the voxel data was the precursor for the system.

Now I just need to update to the latest jme version to get that 50% boost from native bullet. Any ETA on a stable-ish version? I’m still on the 3.0 from the summer of 2015.



Well, compared to my usual coding adventures this system actually works surprisingly well.


It needs to work 100% of the time everytime or else :stuck_out_tongue:


Just pretend the text “Beta 1” is “Stable”. Done.

From another thread, I can call it whatever I want to. It doesn’t change how stable it is. And given that no one is reporting bugs, either no one is using it (because they are waiting for it to be stable) or it’s already stable and the name is just a meaningless fetish.

1 Like

your game has a lot of interesting technical solutions :slight_smile:

1 Like

Looks awesome!

1 Like

The details inside the boxes are only graphical, but the collisionshape is the boxes ?

Only the ones I really need :wink:

Yeah pretty much, physics just dies otherwise. There are some things that check the actually geometry though, like raycast based weapons and such.

Besides, it’s not that noticable for the most part since there’s no gravity and stuff just floats around (no gaps with a terrain mesh for example) and collisions usually happen quickly. Another thing is that I try to design modules in a way that the mesh touches the ends of a collision box, making the inaccuracy less problematic.

Sure you could just roll up to a station or a pile of floating modules really slowly and observe how the shape doesn’t exactly fit but at least there are some sparks flying to distract you :stuck_out_tongue: In the end the extra performance is totaly worth it.

P.S. Now that the rest of the mesh is optimized I could perhaps add some special ones in there, like separate cone colliders for some guns and cylinders for reactors.

@MoffKalast Try to use convex hull collision meshes (no idea how to do it in JME and Bullet, though) for blocks that hardly fit into boxes. They are a bit more costly compared to plain boxes, but much cheaper than actual geometry if done right, giving more accurate collisions with controllable balance between performance and accuracy (by generating more detailed hull or less detailed hull).

As my shadow system is becoming mature, I could not resist making another screenshot:


Ahahaha, good one. What do you think this is? PhysX?

This would separate some modules from being optimized and enable cases where you’d have mesh to mesh collisions. I have absolutely given up on using any mesh colliders, except static ones (which in turn only collide with primitives). The performance of mesh to mesh is absolute shit. Unimaginable shit. Try coliding even just two hull collision shapes and you’ll almost have a thread freeze. At least that was my experience WHILE limiting physics to only 30 fps on a decent i5.

I mean this is like suggesting that I use a mesh collision shape for a character instead of a capsule. You don’t need that accuracy and it costs so much performance that it’s absolutely mad.

Also most modules will have to roughly fit into boxes since that’s how the building system works.

1 Like

A bit of google-fu shoved me this: native bullet definitely does support convex hull collisions as btConvexHullShape and it should give much better result compared to triangle mesh collision, even on simplified meshes.

Question is if it’s implemented in JBullet and how many compound convex hulls you’ll need for complex geometry.

Regarding optimization - it’s completely possible to generate convex hulls in runtime, enclosing multiple blocks if they fit convex hull limitations. And you’re completely free to change collision level of details for blocks - for example, fully enclosed blocks could be simplified to boxes and merged by simple optimization algorithms, while exterior blocks could be subjected to different collision detalisation levels based on overall ship size.

And, by the way, it was you, who said that most modules are boxes anyway - it means that there will be not that many blocks to use convex hull collisions for.

Another thing to note - with good convex hull building algorithms you could use blocks like slopes with no additional cost, and believe me, they look much better than plain boxes. I’m telling so not only from block-building experience in games like Space Engineers, but, coincidentally, I’m currently developing a game with block-building elements using UnrealEngine4 and went through all the way from plain boxes in grid, through various models in grid and, finally, to free placement (still have to find good balance between batching, greedy procedural generation and instancing at this moment).

Just in case if you ask what UE4 user is doing here on JME3 forums - I have JME3 project as well. Kind of - it’s suspended until I have better financial support. Ironically, survival-shooter-sandbox built in UE4 requires much less financial investments than “simple” board game, combining ideas from MTG, chess, civilization and lots of other sources (mostly - unique art and models for characters plus matchmaking servers setup and upkeep costs, and it requires more advertisements too).

BTW, did you try to experiment with Bullet constants like minimal object size? In your world built from blocks it could greatly improve performance (or completely destroy it).

Yes of course it supports them, what do you think I tested with? Even if you surround the entire ship with one convex hull shape it will perform like a strangled cat. There’s just no comparison to primitives in terms of raw speed. Literally using hunderds of primitives is faster than one hull shape!

The problem is that besides the fact that they will run slow, they will also get in the way of regular voxel optimizations, splitting other large boxes into multiple pieces.

No matter how awesome or great a hull building algorithm is it still won’t prevent the engine from lagging when doing the actual collisions.

You have to realize that this is a game where you can’t go outside the ship and walk on stuff with an avatar that would make these sort of accurate calculations needed. About the only physics interaction of ships is through crashing into other things occasionally which doesn’t require dead accuracy. I’ll take quick and close enough rather than accurate and 10 fps.

P. S. I know that PhysX (which UE uses) isn’t big on primitives, hell they don’t even have a cone collider, but the mesh collisions there are WAY faster so one can afford to go that way.

I agree that box collisions are the way to go for your purpose, But bullet hull shapes are fast.
I suppose you are using bullet native from the official builds, if so, it’s outdated and miscompiled, try this build you’ll see a huge difference.

1 Like