My work in progress is a strategy game, except … I’m having so much fun with rigid-body physics that at the moment it’s more like a bowling game
Here’s a screenshot of a “desert fortress” scenario with physics debug enabled:
And here it is without physics debug:
This is a closed-source project based on JME v3.2.4 and Minie v0.9.10 libraries. Gamma correction is disabled. I use Blender v2.79b for modeling, glTF to import models, V-HACD to generate dynamic collision shapes, Maud to debug models, Nifty for user interface, SkyControl v0.9.19 for the sky, SimpleWaterProcessor for reflections, and DirectionalLightShadowRender for shadows. No PBR or audio yet.
is on my todo list, yes. at the moment I made the hits more visible by turning the hit object in unshaeded white for 50 ms. make slow progress as it’s summer and I do not spend much time in front of a computer…
Took me some train rides to refactor my camera stuff to make that screen shake happen when using the submachine gun Including a lerping follow camera to make that a bit smoother and give the character a more “in motion” feeling. Maybe need some fine tuning, but for the moment I’m quite happy, looking forward for the shotgun with a heavier kickback
First i need explain i got grass split into “chunks” 20x20 on terrain.
Each chunk is one Geometry of Grass. (to allow Frustrum cull / distance cull optimizations)
once Terrain was modified in any x,y then trigger delayed Grass update in this system loop.
this Grass update is trully Generating new mesh buffer for chunks (it update mesh buffer) where each buffer single grass blades it check terrain height there (terra.getHeight or some of this methods - yep, it can take some cpu time).
location of grass blades is based on texture intensity + some random pregenerated map (the more intensity the more grass there - almost not visible in video, need some improvements)
i understand it should update “near chunks only” but i left it for later “todo”.
Shader do nothing special, thats most part for “todo” as i plan do wind effect/etc.
so answering your question, it trully generate new Geometry mesh buffer that match terrain height.
currently it anyway looks better now, because of simple change “the more texture intensity, also make grass bigger”, so it make edges of grass areas little smaller that make nice effect.
Cutting grass into chucks is a brilliant idea! But isn’t it better to add the grass directly from the brush without that link between grass and texture? This will let the user to use a countless number of grass types and remove the restriction to use the grass on the same painted material.
I had thought about making a level designer for JME, but stoped for some reasons. What you did is very similar to what I had thought. The grass ,PBR terrain shader and ability to make rivers was also on the project plan (which was a very busy plan). I think that this problem is currently what facing JME for teams (that contains a purely level designers) who wants to make a 3D game. They have to make a level designer from the zero to let the designers do their work alone.
But isn’t it better to add the grass directly from the brush without that link between grass and texture?
i thought about it, thats also good idea paint grass into just “chunk mesh buffers” instead of generating it from alphamap.
current one work for our design, but yes, you might be right it would be better
About “level design” well, we needed to create “own one” because JME SDK one do not allow “game related things” like our own ECS that will just not work with SDK.
Imagine now if you want extend SDK editor you need update it each SDK release too, you need pull all SDK, you have more maintenance to do too.
“They have to make a level designer from the zero to let the designers do their work alone.”
If there would need to be one public, then it should be 100% universal where “everything” could be easly extendable via code and do not require new project like “pull all SDK just for editor”.
Where it would be just “map editor”. What about procedural generated maps? what about Minecraft terrain(Voxel) types?
conclusion: its like impossible to have universal editor that everyone could use for everything.
Its just nearly impossible. I dont think “doing own” is wrong here, unless you create small simple game.
For small vegetation like grass and flowers you want a sprite sheet of x items, say 8x8 images - 64 images in total. Then you use the number as an index and height multiplier. So anything between 0-1 is image 1. Multiply the largest it can be by that number to get the size. It means you have 64 variants of grass or flowers that you can pick or randomly select with varying height.
At least that’s how I’d do it. You have 4 channels (rgba) so you could expand that method pretty extensively.
Ok, I will give the idea more time. Thanks for the help offer.
Am I the only one who has a problem with visiting this hub? Nothing else the main page (hub.jmonkeyengine.org) opens and I am replying now from the email.
Yes that’s true. I tried a lot of those tricks. Not all did workout nicely. In the begin it was just meant to try out stuff of course also all the screenshake stuff from Vlamberr studio. But it feels good actually. It’s fun to use all the weapons I even have a grenade thrower and with press down on the floor it throws a bomb… this is from h.e.r.o. I played on the C64. So I think I will write some small levels and see. I guess in the end it will look different… or not Idk.
EDIT: And yes this is speech from Jan is really enlightening. He do a really nice job, maybe not the speech itself but the demonstration of all the tricks. It’s helpful to see the effects a small enhancement can have.
Btw mean while I also have shell ejection and the shotgun I have does really look great with the delayed shell ejection…
That’s where all my projects failed so far, they all were technical prototypes.
And I feel that this is one of the hardest parts to get right, especially as you can’t solve this like a regular NullPointerException.