// lets just see if this object is 32 world units near us. if not, it's pointless even bothering with it.
int projectileX = projectile.getLocalTranslation.getX() >> 5;
int projectileY = projectile.getLocalTranslation.getY() >> 5;
int projectileZ = projectile.getLocalTranslation.getZ() >> 5;
int potentialColliderX = potentialCollider.getLocalTranslation().getX() >> 5;
int potentialColliderY = potentialCollider.getLocalTranslation().getY() >> 5;
int potentialColliderZ = potentialCollider.getLocalTranslation().getZ() >> 5;
if (projectileX == potentialColliderX && projectileY == potentialColliderY && projectileZ == potentialColliderZ) {
// this potential collider is within 32 world units of the projectile.
}
The short circuit on the if statement makes life even quicker.
As part of my physics engine rewrite, I’m also breaking out Mythruna’s block mesh stuff into a separate (hopefully releasable) library.
Not using any of Mythruna’s textures, of course… those will stay mine. Plus the simpler textures make for better testing anyway since I can give them borders.
Your Bitshifting test does not check if the potential collider is within 32 worldunits. It checks if it would be in the same grid cell if you had cells with sidelength of 32 world units.
eg. for x coordinates 31 and 32:
int projectileX = 31 >> 5 ( = 0 )
int potentialColliderX = 32 >> 5 ( = 1 )
For it to work you would also have to check the ‘neighbor cells’.
(ps. for a ‘within n worldunits test’ you could just use the (squared) distance between vectors)
A few money shots of a new type of cave generation I’m toying with today. It’s not my idea, but is my own implementation. You take noise, posterize it, and select a color. That is to say, you reduce the noise from a possible 0-255 to say 0-7 instead, then pick a number. I’m not convinced it’s what I’ll use in the end, who knows. Nevertheless, it’s quite pretty.
Finally, I started playing around with volume rendering… This screenshot is done with ray marching, but I’m working on an improved version using a low resolution 2D texture array.
Now with limited range raycasts every two frames, higher bullet speed which means fewer tests and a short range, so fewer bullets on screen from each single gun.
I use a similar system, an managed to shoot 3k bullets concurrently, are you sure the raycasts are actually using that much power? And i’m not using the ideas below. Could it actually be the amount of geometries that affect your performance?
Do you raycast in bullet or in jme? (the first is really fast)
Do you create rough collision shapes before (hull around the entire ship) and only test precise if neccessary (using the binary collision group stuff)?
Also read this, and stop using individual geometrys.
Use a custom mesh/instancing
paint via shader bullet in right perspecive and only use billboards or other super fast to render things.
You could abuse the current particle system for this already.
Maybee replace with actual mesh if less than x from camera to reduce artifacts.
Also replace with only one billboard if quite long away, to reduce vertex useage by 50%
X Terran Conflict used this way to render (two X aligned quads)
After setting the ray limit the performance improved substantially so I think it was in fact the real cause. Bullets are made from two quads (or 3 in the turret case) merged together into one mesh and one material which are both static and reused so they shouldn’t be repeated in gpu memory.
I haven’t looked into the real instantiation via InstancedNode/Geometry yet but that ought to bring some extra performance in the future.
I do it in jme so yes, it’s kind of wasteful but at the moment it’s quick enough for an absolute shitstorm of projectiles. Mileage may vary with the amount of stuff in the scene of course.
Raycasting in bullet would be a lot faster since the ship collision shapes are made out of an optimized number of boxes but that gives me another problem. Bullet would only tell me that the ray hit the ship and where but not which geometry got hit since i only get the ship node in the listener. Then I need to do a secondary check to determine the geometry itself which is innacurate (so it’s fast enough) and I only use it for splash weapons that shoot actual physics objects.
Funny thing though, the projectiles from the old plasma cannons are physics spheres which are an absolute hog on performance so that’s not exactly a good sign for bullet. Those are getting converted to raycast soon.
There’s another problem and that is that I’m still on Jbullet instead of native so the speedup won’t be that high I bet. Maybe one day in the future years when the half done port that is native bullet gets into a proper working order with all the features that jbullet has.
Nope, but I have a think that it would have next to no effect because of some internal optimizations that are unknown to me but I can feel them when playing. Like there’s a noticeable performance difference between shooting at a ship and like 30 degrees away from it (with a super large swarm of bullets). It’s like some geometries do a rough distance check and return 0 before actually checking any triangles.
In my experience, using billboards is a huge mistake. In time the cpu will take to orient the quad the gpu can render so much more. Using two quads in a X position + one facing the rear/front merged into one mesh performs much better. Especially if the mesh is instantiated.
Also, axis alligned billboard shots tend to look like absolute crap from behind, which is the exact way the player looks at them for most of the time.
I’d have to really deconstruct the emitter for this though. The local and world space simualtions aren’t right for my setup and I’d somehow need to figure out how to create large custom meshes from 3 quads per piece, keep track of those pieces in a mesh somehow and make them interact with the world…
I have better things to do for the next year and a half that this would take to fully figure out. Especially with the easy alternative to simply lower the fire rate a bit and buff damage.
Yes, CPU billboarding is for chumps. Since empire mentioned batching, I’m going to assume he meant GPU billboarding… which has all of the benefits and none of the drawbacks.
Of coures why do shit on cpu, if a vertex shader can do them
That way prepare a offscreen mesh rendered at +1million, and just move the required billboards in, static performance at all times no changing memory requirements, communication with shader via an float array for the positions
