Wicpar

To be able to simulate orbital physics correctly, you would not only need frames of reference but different voxel octtrees: one per structure. 
 
The system is simple:
the universe has a plane of reference containing solar system planes of references, those are static.
Solar systems store the combined center of mass of all bodies in the system, and create the orbit ellipsoids around it. the center of mass moves with the planets and thus simulate the N body system in some ways (the orbits have to be slightly changed every update but that is quite cheap as it is a change in position of the body, but not changing the energy.
 
same goes for planets and rings/moons/asteroids etc scaling down. when it comes to planets frames of references in atmospheres, those are relatively static, (unless there is a superstructure but that will not happen in the next 2 years) and thus can live directly in a child/parent reference relationship.

Servers HAVE to calculate physics, and physics are cheap if well done (using octtrees etc...). The problem is to share the data between players as it is quite cpu-time intensive. By deferring the physics on clients you would need to verify and crosscompare the results of ALL clients in an area and determine if someone is cheating, and then update in case there are precision errors etc... which is more expensive than actually calculating the physics on the server. It's just a matter of adding vectors and doing simple integration. Collision tho, is the real problem, and that can only be done server side if those can damage cubes, since the quantity of data to collect and analyze would be ludicrous.
 
Not talking about hackers or community modding to counteract this measure and exploit that democratic system.
 
Hope it helps you understand why it can only be done on servers if you wanna be able to let people with a small upload speed play correctly.

i would even extend that
 
i would even extend that, saying you have to manage inertia as gravity, so we can create artificial ring gravity (with rotation), just align the player with the force vector when in collision with a structure or vessel.

That idea is great, but please note that sensors are not using magic to detect, they use EM waves, and those can be absorbed and/or reflected and/or detected.
In the case of detection, pure passive scanners (like cameras basically) can be used to prevent detection, but those give quite lower resolution or ark of detection.
You can detect active scanners with active and passive scanners, because those light up in the direction they detect in.

That idea is great, but please note that sensors are not using magic to detect, they use EM waves, and those can be absorbed and/or reflected and/or detected.
In the case of detection, pure passive scanners (like cameras basically) can be used to prevent detection, but those give quite lower resolution or ark of detection.
You can detect active scanners with active and passive scanners, because those light up in the direction they detect in.

if they are anyway near to make a 2000 player battle, they surely can have an array of GPUs: 13 * 2000 = 26000 = ~20 nvidia Titan X
which has a total of 20 * 3584 cuda cores which can calculate the physics of a whopping 71680 bullets physics simultaneously:
2000 instructions per shot physics tick (very generous estimation)
so it can calculate 1417000(base clock so probably even higher) / 2000 * 71680 = 50785280 theoretical bullet physics per second.
which would be half for a 1000 player battle.
(memory is negligible as only the relevant physics voxels will be loaded in vram, which would hardly approach 12 gigs)
 
You, my sir, have ludicrous claims.
Have a nice being destroyed (no offense, just for the drama ).
 
EDIT:
 
I have mistaken (yes self destruction), one gpu cycle does not coincide with one instruction, and thus will more likely be in the realm of 10 million theoretical bullet physics per second because of the 6 instruction stack size for 20 titan X, please note tho this only describes latency, and such a scenario can only happen if the program is really badly made and compiled. and will such be still around 50M

This is MY vision of what sensors should look like.
 
Low Gain Omni Sensor:
 

 
High Gain Omni Sensor:
 

 
Low Gain Directional Sensor:
 

 
 
High Gain Directional Sensor:
 

 
BEAM Sensor:
 

 
 
ANYTHING detected within the AREA of the sensor, is reported back to the DPU. 
 
 

that is not true, the warp drive works by removing space before you and putting it behind you, this allows for great absolute (because relatively you still accelerate slowly, but the smaller space multiplies the effect) acceleration without G forces, the only drawback is that you only can go in a straight line, as it does not reduce rotation based G-Force. 

There is a misunderstanding here, on that kind of mmo you cannot let people calculate their physics, only their graphics. Latency is irrelevant since you send input to the server and get the changes of everybody back. The only latency you get is when you shoot and move, and that can be mitigated with a small load timer on the gun and movement prediction and interpolation.

i would quite disagree, G forces have a big impact on space travel. without G-Forces we could use a big cannon to shoot people to mars and done, but that is ludicrous. without G-forces the difficulty curve for agility builds is quite linear towards thrusters tech level and fuel efficiency, but with G force you would have to add exponential inertial dampener transforming that curve in a more logarithmic one, as you need more mass to go faster thus going slower a bit than you would without.

Voxelfarm, the voxel engine novaquark uses, supports uv mapped voxels, thus it is logical to allow painting textures.
BUT
I would be willing to go further: allow people to make their own shaders, this would allow for interesting features like metamorphic hulls, that change depending on the environment for optimal camouflage. a test would be made tho, on upload, to see the performance impact of the shader. it would not be allowed to take more than n millis to render for performance reasons (so you don't start doing raymarching)
 
how to implement it in the shader pipeline: quite straight forward:
 
if the pipeline is standard rendering: 
vertex shader- > geometry shader -> custom draw shader
if the pipeline is deferresd (if not you have to implement it for performance)
vertex shader -> geometry shader -> shader that combines custom shaders: vertex color determines the shader to use, and use GL_NEAREST to determine the shader to use. opengl supports async shader compilation, thus removing the need to drop performance too much. then it outputs the color, depth and uv. depth cannot be changed by the custom shaders.
 
this is ideal because you would then be able to put logo animations on the hulls an do all kinds of cool things. It could increase the creativity of the factions. and such shaders could become commodities. the shaders would need access to some vars like shadertoy does to be able to place virtual decals, patterns etc... 
 
unless you want to sell skins for pecunia, i don't see why this would be objected too as it is purely client based thus have no server cost except in the upload phase. Even a mod could add that easily.

even in large battle it would be possible to maintain if the calculations are parallelized. I already did something similar in my physics sandbox, i multiplied performance by 100, literally (there were caveats, but they were due to hardware limitations (physics precision)).
A good opencl handler could handle about 10000 - 100000 physical moving shots on an average gpu (770m) easily. (has to have physics ordered in an octtree)
 
well, if it was only relying on me you coud plug a gpu on a potato and dual universe would work efficiently lol.

I like to think of it as a service, which it really is. And I know to support services (technical infrastructure, customer support, ongoing development, etc), there has to be a baseline revenue stream.. a steady subscription forms that base!
 
Don't forget there is no $60 cost (or any cost) to actually buy the game as well, and you can buy subscription months just by playing the game.
 
Seeing as how this game is crowdfunded and privately funded, all of the revenue goes back to the developers not a publisher and you can bet JC and team will reinvest substantially into bringing new features and content to the game!

I concur with OP. Hopefully, Novaquark can come up with a hybrid system that allows for actual projectile physics in less crowded instances for a more realistic experience.
Relying only on tab locking reduces dog fighting and ground infantry combat to aiming and dice rolling, which is IMHO a contradiction to the otherwise modern approach of the game.

Hello Dualiers,
 
The plan right now is (according to what i have seen and heard) to have a stats based locking targeting system. it is extremely cheap. too cheap. the problem with it is that the battle becomes more of a dice roll, as can be seen in eve online. You target point blank on a battleship (miss) wtf... these kinds of things are frustrating.
 
there are tons of ways to contour the problem with kinetic weapons and their delay, the easiest way to reduce performance drain is to handle them like a shell + their movement, it calculates then an intersection on that 4D-ish object (it is in practice flattened into 3D) every frame, not more expensive than having a player. then you can put a limit in the form of reloading time, real battleship shells take 10-20 seconds to reload in best of cases.
 
besides that, lasers are practically free, but do less damage, and have tendency to overheat so you have to stop them quite often if not reducing their lifespan considerably, and use a lot of energy.
 
you get the idea of the gameplay implications.
 
this system would allow to handle all weaponry shots in one container, thus reducing development costs and code base pollution risks.
 
this is mostly important if we want to make weapons interact between planets and space, as punching a hole in a vessel in space would be ludicrous from the planets surface. and what about 1000mm planet-space cannons, do these not ark? 
 
in addition to that this system would allow for massive increase in need of good targeting scripts or canoneers (there would be visual aid for players (can be cheaply calculated with raymarching, but  it is relative t the memory architecture you chose for the physics mesh, if there is a phase where it is static in the loop, it may be worth it to do it asynchronously in a separate thread if it is the case)
 
eve online opted for that system because it uses 1 second ticks, i don't think you work like that, and if it is the case there is no advantage to it except a relatively small amount of computations, as you would have to determine the voxel to break anyway...
 
and what about people who want a fast fighter with Gatlings? locking would be so unsatisfying, especially if you target a starbase...
 
but anyway, this is my opinion and my vision of locking may be wrong.
 
hope you find this idea interresting .
 
just remember, my point is control vs simplicity (pro control).

Hello Dualiers,
 
The plan right now is (according to what i have seen and heard) to have a stats based locking targeting system. it is extremely cheap. too cheap. the problem with it is that the battle becomes more of a dice roll, as can be seen in eve online. You target point blank on a battleship (miss) wtf... these kinds of things are frustrating.
 
there are tons of ways to contour the problem with kinetic weapons and their delay, the easiest way to reduce performance drain is to handle them like a shell + their movement, it calculates then an intersection on that 4D-ish object (it is in practice flattened into 3D) every frame, not more expensive than having a player. then you can put a limit in the form of reloading time, real battleship shells take 10-20 seconds to reload in best of cases.
 
besides that, lasers are practically free, but do less damage, and have tendency to overheat so you have to stop them quite often if not reducing their lifespan considerably, and use a lot of energy.
 
you get the idea of the gameplay implications.
 
this system would allow to handle all weaponry shots in one container, thus reducing development costs and code base pollution risks.
 
this is mostly important if we want to make weapons interact between planets and space, as punching a hole in a vessel in space would be ludicrous from the planets surface. and what about 1000mm planet-space cannons, do these not ark? 
 
in addition to that this system would allow for massive increase in need of good targeting scripts or canoneers (there would be visual aid for players (can be cheaply calculated with raymarching, but  it is relative t the memory architecture you chose for the physics mesh, if there is a phase where it is static in the loop, it may be worth it to do it asynchronously in a separate thread if it is the case)
 
eve online opted for that system because it uses 1 second ticks, i don't think you work like that, and if it is the case there is no advantage to it except a relatively small amount of computations, as you would have to determine the voxel to break anyway...
 
and what about people who want a fast fighter with Gatlings? locking would be so unsatisfying, especially if you target a starbase...
 
but anyway, this is my opinion and my vision of locking may be wrong.
 
hope you find this idea interresting .
 
just remember, my point is control vs simplicity (pro control).

i have developed a technique that can reduce the cost of aerodynamics by a lot: take the ship, put an orthographic camera in front of the ship, to point in the inverse direction of the move vector, then draw the ships normals like in deferred rendering. using opencl-opengl cross compatibility, calculate the drag of each pixel and apply that force to a virtual ship construct in opencl memory, and then bring it back to cpu and apply it to the ral object. please note you have to have the center of mass of the ship in that specific camera space to be able to calculate the rotations.
 
that said, maybe PhysX has better to offer, but i never looked it up and it wouldn't be cross-platform. this is the most efficient way to do it by far, and is done in one draw call. Opencl supports async rendering so you may take advantage of multi threading while waiting on that step. for server calculations, it is a little inconvenient since you need a gpu, but it is worth it, i have worked with GPGPU quite a bit and would be happy to give you everything you can compute on maybe a tesla rack or else. ideally the server would use cuda, it has opengl interop too, and is way simpler and more powerfull to use, and the dev environment is cpp, and nvcc optimises like crazy. anyway, if interested i will be happy to help you.
 
one other thing: if you do so: do the accurate mathematical formulas(integrations), it's a little more expensive but the difference is massive on multiple iterations... i learned it the hard way is my physics sim sandbox.

one dollar a day keeps the assholes away
 
that's why there will be a subscription fee, it filters people that want free fun by ruining other's