First thought: Wow, those procedural clouds look amaz-- ah, that’s a photo. (At least I had faith in your ability, right?)
Maybe you’re aware of the sampling data loss, but I’ve seen the same craziness happen when sampling data at a lower resolution than the source image. I think that’s what happening here. Skips over data entirely, causing deltas that are far more drastic than you’re looking at in the photo.
I guess your source image dimensions (assuming it’s just sampling pixels) didn’t match the number of vertices in the ground terrain. Or maybe you don’t have much control over that because of LOD. But if you’re further away, the sampling difference shouldn’t matter as much, so “turning up the LOD to ultra settings” would probably also help, if that’s possible.
Good idea. It would add some detail back, but I’d still have to figure out something to fix the jaggedness.
Both the image and the terrain had 1024 pixels/vertices. And yes, I turned the LOD distance to 9001 because everything looked garbage otherwise.
Not quite sure what correlation would sampling data loss have here, could you elaborate?
I guess you figured already, but I just meant that if you’re sampling a 5000x5000 pixel image but you have far fewer vertices (500x500 or something), you’d be losing data needed to make the terrain changes gradual. But since you’re not doing that, it must be something else.
Maybe you just have too large min/max range (“levels”?). You could try increasing contrast on the source image (and reduce max height) a bit to get some more shades of grey. Looking at it a second time, now I kind of doubt you’ll get a good “mountain” style terrain out of it, without major manipulation.
I’ve done a bunch of heightmap experiments with pre-generated perlin noise before… that experience makes me feel like the whites in the picture are a little too similar to create mountain-like terrain. And the blues especially so. Those areas should be basically flat. I’ve found that if you multiply your values enough, even a fairly “flat” looking heightmap gets crazy.
For example, there’s a lot more variance in the white and grey tones here, which I think would create a softer “hilly” region:
And to compare with real life terrain, I have some GIS software (QGIS) here where I grabbed this sample from. Pretty big differences in brightness (Swiss Alps):
A bit high altitiude to work here though.
I only used Unshaded.j3md for this game - most of the scene lighting was actually baked into the texture atlases.
For the other shadows that weren’t baked into the colormaps/atlases - i.e shadows that needed to move with their objects - I positioned a plane, dedicated for rendering shadows, right under the object that needed the shadow (or parallel to the plane it was resting on) parented to the object, then baked a shadow onto it using AO.
I didn’t use any filters. Apparently they are costly on mobile. The CCTV monitor effect is just an image overlay.
yes, the flag is really cool i want it in game! but also would like use default JME code, so will wait because got too much work anyway(i understand it will take time, you also make a game i hear, curious what it will be)
My closed-souce WIP is a strategy game I started back in 2013. (I’ll post a screenshot someday.) It uses Minie, but as far as I know it won’t need soft-body physics.
I’m working on soft-body physics because I think it’s cool and I hate to see Dokthar’s work languishing in a private fork, untouched since 2016. I hope people here will dream up uses for it and those uses will motivate them to use Minie.
As long as JME supports both jme3-bullet and jme3-jbullet (and tries to maintain compatibility between them) I doubt soft-body physics will ever be part of default JME.
also hate feeling like something will change in JME so Minie will be uncompatible, and you will have no time for fixes.(because life is life, noone knows)
That is the only think why i would prefer see Minie features in JME.
Have you thought to make some JME package jme3-bullet-extended that require jme3-bullet package and will just not work with jme-jBullet?
because it already is same about
android packages
or just about
“cant use both jBullet and bullet”
and maybe even more dependencies.
why not next point like:
dont use jme3-bullet-extended(or jme3-bullet-minie) with jme-jBullet
i would love to see it just as JME package so further JME development would not change things to broke it in future.
Your work is awesome, so i will use it for sure, but have this dillema since start. Anyway for now got too much work to do, so i hope in meantime maybe you will create some JME integration.
What’s stopping us putting jbullet in stasis? If the recommended library is now native-bullet - why continue development of the java one? I ask out of intrigue.
My last update this month
Added dead and destruction including some simple explosioin effects. It’s a lot of fun to play with all these game feeling stuff. I got a lot of ideas from Jan Willem Nijman ( “The art of screenshake”) but also from the game Mugsters which has very powerful looking explosions.
My explosion starts to look and feel nice, but I have to play with the direct impact radius (should have a larger horizontal impact) and I probably have to take in account the speed/mass of the fragments, else it might look a bit silly if an opponent dies because of a slow approaching fragment
Did know that game Btw. the bomb launch idea I took from the very old H.E.R.O. game where you had pull down and press the fire button (in my case you only have to pull down).