Well for a couple weeks I have been busy adding bidirectional sync to LSF Blueprints mobile app. The feature still needs some work, but mostly it’s done.
3 Likes
The game has Finnish origins. Torilla tavataan! 
What happens when you add stairs to the mix?
what do you mean?
Stairs are special grid that overrides one wall and are bigger than single square.
2 Likes
Well what I mean is that the level builder is 2D and that kind of doesn’t allow for multiple floors above/below the current level. I assume you do it by making each floor on a separate design plan, but how are they linked together?
Yes, every level is a separate map. I just need to be careful and place stairs in proper grids. When player enters the stairs he will automatically move forward +up/down for one extra square with a fadeout effect on the screen, after loading he will find himself standing on the next floor. There is no link between stairs, they are not paired.
2 Likes
You definitely needs to add some shadows.
1 Like
So, this past week I started rewriting my physics engine from the ground up based on several years of lessons learned. This time I intend to build in ‘zones’ right from the start. Part of this was a redesign to clean a bunch of things up so it’s always exciting when it starts working again. Even kind of more exciting when I find and fix a bunch of bugs that existed in the math for a long time but only now are easy to find because of the better infrastructure.
I’m building this as part of a suite of Mythruna-related infrastructure that I may open source separately at some point. It kind of just depends on how far it goes and if it stays clean enough.
Anyway, not much to see but I do have some screen shots today. These are pictures of my demo app that I use to test things. I can shoot various size ‘bullets’ as well as drop big 1 meter radius bombs. This sequence is after I spammed a bunch of stuff and I’m watching it settle and the temperatures cool down (I use simulated annealing for improved accuracy but that’s another story.) The solid shapes are static. The textures shapes are the bullets and bombs and stuff.
Here…
14 Likes
that is really sexy 
Man that is great,
Doing GUI stuffs, Networking, ES , FX , Terrain, Math, … and now Physics stuff.
You are just an awesome man. 
In a side note:
It takes me an hour or two to read your IsoSurfaceSemo topic in other thread. It was also awesome. Thanks
Very cool, but it seems to me as reinventing the wheel. What’s the catch (if you’re not just doing it for the sake of learning and/or having fun)?
I mean native bullet should always be faster than any java implementation, unless you’re doing something to optimize it for voxel worlds.
Ive tried to put shadows but I don’t know how they work.
From what I understand JME 3.1 handles shadows different.
I’ve tried the post processor filter but with no effect
Wrong topic IMHO open a new topic and provide code. Best is if you write a test class to visualize what you did. I guess your objects have not set cast shafdow/receive shadow, but yeah provide a test class…
I think that java code with effective JIT can generate more effective low level code 
Yeah… It’s not that big of a deal to me. I was just replying to someone else.
I have no interest to be honest.
There were two reasons. And first, I recommend everyone to use someone else’s physics engine. Writing one has been one of the most painful experiences of my life but I started it about 5 years ago, hung some features on getting it working, and have been hacking at it ever since. Unless you understand the math 100% (and I don’t), say away: here be dragons.
Anyway, I did it because I wanted control over when physics ran. I desire to simulate hundreds of user-created objects across a whole “infinite” world. At the time, I wasn’t really sure how to make bullet do that… (nor was bullet native a viable thing back then, by the way). The irony is that after having finally started to add this feature to my own, I see how I might have done it. Bottom line: I always planned to build this in at the core. I’m finally getting to that.
The second reason was because I wanted mesh accurate object-to-object collisions. It seemed to me that I could get pretty close by doing optimized voxel-to-voxel projection. That part has worked out pretty well. Early tests of the engine were pretty encouraging… I could even nicely calculate center of gravity and the intertia tensors.
Here was an older video (from 2011) where I fixed some stability issues but hadn’t added back object-to-object collisions:
At the time, I wasn’t even sure I could have made bullet do even that much with fully custom game-runtime-defined meshes. After all, those tables and chairs models were created in game.
While it has been an incredibly frustrating journey, each new milestone is that much sweeter. Plus, debugging math you don’t understand helps work those problem solving parts of the brain… and each time I understand what’s going on a little more.
Here is an even earlier video that shows when object-to-object collisions were totally bonkers:
Note: even now object to world collisions are done as if the object’s voxels were full blocks. For object to object collisions, it picks the one of the objects to be in ‘full block mode’… the target of a collisions can have full partial block collisions just like the world does.
So I just wasn’t sure bullet was going to give me all of that control. Though if I never get this working, then that’s the route I will take and just cut about 15 features out of the final game.
Edit: and PS: I’m writing this as if I will open source it… which isn’t a promise but my track record is pretty good so far at least… so some day others might be able to learn properly from my mistakes.
7 Likes
I went ahead and uploaded a demo if anyone else want’s to play with it:
-direct URL removed because I think having it on here directly is messing with the download stats-
Download is kind of slow for some reason… I probably should have stuck it on bintray or something. Full landing page for what it’s worth:
Anyway… WASD + mouse moves/looks. Left mouse fires big bullets, right mouse fires little bullets… space bar drops a bomb at the section of ground you are looking at. With no crosshair it’s kind of find to guess.
The settings are currently optimized for stability so it’s possible to get the balls to hang over the edges of the cubes and stuff if you hit them right. I’m also not sure why friction stops the small balls instantly on a rebound. It may be due to some other friction changes I made and it may just be a fact of counter rotation + high friction and low restitution (bounce).
Either way, I will always err on the side of stable versus chaotic. It works better for me and my game. (And hours of playing Skyrim makes me feel much better about my physics engine, anyway.)
1 Like
So in a traditional tester fashion I threw an autoclicker at it…
I gotta give it to you, the performance is quite good (I was running at 25 fps on a i5-4760K in the pic) despite me spawning in thousands of balls. I bet you could even do fluid simulations with this if you set friction to zero and removed the code that handles rotation (possibly speeding it up further?).
I remember doing a similar test in Unity once (with PhysX) and it ran like absolute ass. It may have been more balls though.
Well it seems to me that the overall friction coeficient is about 10x too high which may contribute to that.
1 Like
Yeah, a physics engine with just spheres and no rotation is WAY simple. Probably 70% of the math is related to resolving contacts and imparting torque, etc… Quite complicated. So a pure point mass engine is very fast and I do indeed plan to use that for some simple fluid simulation… but more in the “fire these particles and watch where they go then bake it” kind of way.
It’s a complicated dance in this case. Friction, dampening, and the temperature annealing all come into play. For example, if I set the cooling factor very slow then everything becomes more chaotic and the other numbers make more sense. Similarly, if I lower the linear or rotational dampening then things won’t cool as fast anyway. Friction is at least per-contact but defaults to 0.7 right now. Nice thing is that I could have some surfaces with different friction to test if it’s a bug or a parameter problem.
Anyway, given what I want to do with my physics, I prefer it if objects stop too quickly versus not quickly enough.
It is fun to watch the giant fields of spheres have waves of colors as they attempt to cool, reheat, etc. as new contacts come in. One of my favorite things is to wait until it all goes light blue and then fire a tiny bullet into the middle of it.
Thanks for trying it out!
Edit: F5 will turn on the regular JME stats so you can see how many objects in the scene there are… which is at least a rough count of the spheres (+ some additional handful of objects).