Wait, what’s your problem?
I haven’t fiddled with the drop shadows for ages.
Just a little video to show real-time deformation of a marching cubes mesh. A lot more is going on here than shows. I’ve re-written the triplanar shader to use a texture array instead (hence the wierd textures - for checking they are applied properly) and implemented a voxel-type system into the mesh (basically using the texture co-ordinates to pass the voxel type (which material to use in the shader textureArray).
I wish I could share the code, but I had to chop up @pspeed code to get it to work. I had a few issues with the way he had it set up; namely the child-parent relationship combined with the priority queue.
In essence the way Paul did it was by building the ground first (parent) and then the vegetation afterwards (children) - which makes complete sense, but given that each child is generated on a separate thread, it meant managing the child threads - waiting for them to complete before putting the finished article into the scene. I didn’t need that flexibility. I needed a whole chunk (children and all) together, and it made sense to do this all in one single thread for me.
Secondly, not sure if you’ve payed much attention since Paul, but you kind of inadvertently created two priority systems that kinda compete sometimes. What happens if I set the ground to priority 4 and the grass to priority 2? The grass can’t be built without the ground. For me it was a bit more complicated than I needed it to be.
And for some sky stuff. Not all my code, but a lot of it re-written to my liking and put into an appstate. I do plan on giving this sky code away in the form on an appstate.
5 Likes
I would like integrate it to my editor 
Feel free - it’s open source.
It’s good, and what about your mesh deformation?
Well I can’t really because it’s code for a game I’m writing; however, since I’ve been reading on it and know how to do it now, I will instead extend upon paul’s existing open-source code (which my code derives from anyway) and share that. That way it all stays nice and clean and whomever is interested in marching cubes can work from a single example.
1 Like
I’m going to start implementing a component SceneEditor in my editor after the version 0.9.0, so I think about which tools I can include to this.
1 Like
I guess the stuff you need to save you a lot of time is this code, keywords being voxel brushes and neighbor finding. As you can tell, it’s just ripped straight out of my code. I haven’t prettied it up.
Not that hard once you cast your eyes across it.
Second problem you will face is generation time. You cannot create huge chunks fast. Sad story. Make small chunks. 16x16x32 or something. Build a new chunk, add it to scene, remove old chunk.
Next problem I guess you would like to know is texture atlas-ing voxels and all that fun. Maybe another day 
https://gist.github.com/jayfella/7a5b87830ae8ec975ec7633a3bcd68c9
Omnidirectional turret cannons.
Took way too long than it should have and looks completely messed up in blender so it can work when exported and operated with code in a hacky way.
Who thought it was a good idea to have all bones rotate around the armature origin instead of their local origin? Nuts.
9 Likes
sounds good!
Another day in paradise 
Oh, and I got muzzle flashes working:
The rotation kind of works but it tends to give up when you try to look backwards. I’ll have to actually take a look at the math instead of just mashing quaternions together and extracting angles 
8 Likes
I gave bones completely up in my game for the turrets,
instead I have naming pattern with pitch, yaw and roll, and just rotate directly the corresponding nodes in jme
1 Like
Well yes, that’s how I have it done for the lasers, but I’m already pushing the number of geometries with one per module so I absolutely need to have as much stuff in a single mesh as possible.
Doesn’t mean I can’t bitch about the exporter absolutely messing this up though 
I fully figured out the rotations now! The video sound is a bit off since youtube deleted a music track that it didn’t like.
https://www.youtube.com/wach?v=Hg6dvVWywgk
Turbolaser towers anyone?
It’s very apparent in the video and less while playing but the fired shots do make quite a bad performance impact…which isn’t due to the graphics but the target detection.
Each shot does a raycast for the distance it will travel in the next frame to see if it hits anything, which is about the only way I could make it work really accurately.
All projectile weapons so far have been physics based objects which had a tendency to skip through targets even with ccd enabled since I have to discard the collisions between them and the other bullets which somehow makes it skip reporting collisions with other stuff.
Does anyone know any cool (see: better) way to do this sort of collision detection? I suppose I could do it every second frame instead of every frame but that’s not really a solution.
3 Likes
If all velocities are constant cant you intersect? Disregard. I watched the video. I see your dilemma. I guess static objects are easy enough doing that, though.
Well I don’t really have any static objects, aside from planets, stars and nebulas which don’t have colliders anyway.
But I’m not exactly sure how would I use intersect here? Go over every object in the scene myself and check if the ray intersects every triangle separately? I’m sure collideWith does that anyway so it’s not like it would be any more efficient.
I was thinking maybe a one dimensional box collider (e.g. (0,0,length)) may perform better since it would only need to check the distance instead of up to inifnity like rays do, but I don’t know enough to say.
I really wish there was a way to limit rays so you’d only need to check the small part of it.
I guess this isnt the best place in the world to discuss this, but I think this comes down to scene management quite a lot. From the projectile standpoint it can only hit what is directly in front of it. If the scene is managed correctly (by using some sort of octree management maybe) it would only need to iterate it’s immediate local potential colliders.
I mean you could even use simple bitshifting on the position of items here just as a base test to see if that object is even anywhere near your projectile. That would be a quick test.
Yeaaah, that if statement returns false.
Any way without mangling the entire engine? 
1 Like
edited my original answer
I am pretty sure that there was a length Parameter with rays, i think I am using it for the weapons Range limitation.
Apart from that you want to collide with the bounding boxes and then get the triangle of that bbs mesh.
Probably that is what is already happening behind the Scenes though
Oh hey, you’re right! There’s a setLimit() which is set to Float.POSITIVE_INFINITY by default. 
I wish I’d looked at the source earlier.
Now to fix every raycast I’ve put in in the past two years…