post release: What to do about nebulas

Talk among developers, and propose and discuss general development planning/tackling/etc... feature in this forum.
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Re: post release: What to do about nebulas

Post by chuck_starchaser »

klauss wrote:You have the wrong impression from openGL. OpenGL won't do anything you don't tell it to. If you want to cull, you have to code that.
If you send a million asteroid objects to OpenGL, it will attempt to render them all. It will process the vertices, transform them, and remove primitives that lay outside the viewport. It will rasterize the remaining ones onto the screen. So it will cull to some extent, but it will process (at least minimally so) every and all of them.
It's the graphics engine code the one that culls at the object level, it's VS code, code that you or I or someone else has to write.
Well said.
Safemode, look at which games from which game company have the best performance. ID, all the way. And what do ID do different?
They got half a dozen layers of culling, in the cpu, long before opengl.
They got portals AND hint planes AND bit arrays representing any cube of space to any other cube of space visibility (super-fast) AND then they got frustrum culling AND screen-space occultation hacks of various kinds ... AND then BSP. Z-buffer based occultation is the kiss of death, performance-wise; a per-pixel test. It's what you rely on for visual correctness when everything else fails. The only culling done by the gpu that is fast and efficient is back-face culling.
safemode
Developer
Developer
Posts: 2150
Joined: Mon Apr 23, 2007 1:17 am
Location: Pennsylvania
Contact:

Re: post release: What to do about nebulas

Post by safemode »

Was busy yesterday night, so i'll start with this part of the post for now. cuz ..well why not :)
klauss wrote:
safemode wrote:Similarly, gravity from Planetoid A is not owned by the system. It's owned by Planetoid A. I dont see the need to divorce this relationship.
But this isn't. What would planetoid A want to do with the force field?
If anything, the forcefield wants a reference to the planet to track its position. But the planetoid has absolutely no task involving the gravitational field. It can't change its mass - unless you want to model that possibility. Which I'd advise against.
That inversion of ownership is a classic transformation when modelling a solution for a problem. More often than not, the "arrows" in the solution get inverted. Don't ask why is it so common, it just happened a lot in my experience. I can only answer why it's practical in specific cases, and say that I've seen a lot of those cases.
If we make the script owned by the system, the system has to look for units under it's effect. It has to do this every frame. If we make the script owned by units that would be under it's effect, it's automatically run whenever it's needed to. The unit can't get away or out of control, and we dont whore the cpu traversing the unit list. The caveat, is that that which it is gravitating towards must be relatively static. This is kind of related to the problem bases have orbiting planets that are in fast motion, where the planets have gotten more physics frames than the base. How handle this can be somewhat simple. We could allow units that have matched the velocity of another unit to become something of a satellite of that unit, such that when the parent unit has a physics transform, so will it's satellites. This ensures anything orbiting anything else (assuming they used their match velocity/enter orbit button or were scripted that way) always stays in sync.
quote="safemode"]damage functions are handled at the receiver, not the sender. Yes, we should have separate methods for radiation / heat and kinetic damage. How the unit chooses which to enact should be a product of the weapon object. The weapon object can be thought of as a packet that can contain multiple types of damage. It doesn't physically write those damages, they're more like energy levels of different damage types. We could create a weapon that has some of it's energy in the form of heat and some in the form of kinetic energy. we could create one that has some heat and some radioactive. Either way the weapon object imparts this information to the damage method of a unit it contacts and the damage method decides what if anything to do with it.
Aren't you describing affectors?
[/quote]

An effector as far as what has been termed here has been a sourceless faceless script that is triggered by entering some bounded region of space, much like how entering a nebula causes your radar to get glitchy (and stay glitchy due to a glitch)

I'm talking about something more akin to a message quanta. This message quanta re-uses the weapon subsystem ...which already is a message based quanta subsystem.

In this setup, the source of the effect is responsible for sending (attacking) a unit in the sphere of influence. So basically, your unit gets too close to something, it fires off it's radiation "weapon" at you and you start taking radiation damage. But really, all the source is doing is sending you a packet describing what the packet is, how much energy it has and where it came from. The where it came from is important, because it's the target unit's damage subsystem that determines where the "weapon" hit. Not the attacking unit. You can't say that shields on the left side of the ship are being depleted faster than the right if you dont know that the attack is coming from the left. Similarly, if you are being bathed in radiation from a star, the side facing the star is going to be the one getting the brunt, so you have to know where the radiation is coming from. You can't just say it's up to the user to realize it's the star. The damage subsystem on the unit needs to know in order to determine where to place damage.

safemode wrote:The weapon object does not care what kind of object it intersects, or if it has an effect or any of that, it's all up to the recieving object to deal with it, and produce the effect of the weapon hitting shields vs hitting the hull if it has shields ...etc etc.
Yep - but the weapon object has to make the call that applies radiation/heat/whatever to the unit. It won't modify the unit's state... it will merely send the message: "you've been radiated".
the weapon object makes a call to a general "damage" function. That unit's general damage function makes the call to do whatever it needs to do with it. The weapon doesn't decide if it's absorbed by shields vs hitting the hull. The weapon doesn't do anything specific other than tell the unit it's been hit by something. The unit's damage function investigates what that something is and what to do with it and where to put it. Now it can definitely get hinted as to where to put it if we're dealing with physical objects since it will also know where exactly on it's mesh the intersection occurred, but for the most part weapons do not have a mesh and so (until we get the raycollider setup) this is inferred by knowing the current location of the source.
safemode wrote:By a star using the weapon object, i'm using a mechanism that is easily suited to handle putting out damage to things that recieve damage.
I don't get what it means that a star uses a weapon object.
Just that it's using the same means that weapons use in order to impart forces on units. basically think of the star as a massive base that hates everyone and when anyone gets too close, it shoots them with everything it's got. Heat, radiation, whatever.
safemode wrote:Rather than create a new mechanism to impart things like damage. Stars or other astronomical phenomena that create things like heat and radiation and such would in effect be a beam weapon coming from the source of the radiation /heat.
Aside from the apparent soundness of that, I'd like to point out what I already pointed out. Re-point if you will: it may be worthwhile to create a different mechanism for a different purpose. An attack, an explicit aggression, is different from an "accident", like hitting a radiation field or, perhaps, colliding with another unit. The difference is intent.
So a different mechanism in code may simplify the need to convey the difference in intent.
i dont get what intent has to do with anything involving damage control... if i shoot you in the chest on purpose, you're still going to bleed just as fast as if i shot you in the chest by accidentally dropping the gun on a table. Intent only matters to the AI or player, and that can be inferred by the situation.

trying to identify intent on a procedural level is much more complicated..and involves remembering the past. You can't receive enough information about intent on a frame by frame basis.
safemode wrote:Your ship would register this as such, and even be able to identify the "attacking" object...much like you'd be able to determine the location of a radiation or heat source in real life.... something that would be very problematic in the case of an "effector field"
The ship doesn't need to identify the source - the player will have to.
AIs... maybe.
But then again, AIs only need to know to stay away from certain areas - there may be no need to code survival intelligence, you can simply code a general "stay within these areas" rule.
So lets tacke AI when we get there... right now talking of AI at that level is hand waving at best.
here i disagree strongly. The ship has to know the source in order to place damage. Even in situations where the source is not needed to place damage due to mesh collision data being available, such damage would have to be coming from a uniform direction and any decent radar would give you some indication as to the source.

Rather than have a script for every single situation controlling AI's, AI's should only need a general behavioral script to help deal with avoiding continuous damage, and all the information they need to deal with it will be there for them. we can avoid talking about AI but when you are talking about planning these things you have to provide a mean for an ai or the player even, to have the appropriate information in order to react to them. Damage without direction wont work. Damage with direction has to come from somewhere, whether your computer automatically paints such an object hostile or not doesn't matter, but the fact is that any radar system in the VS universe should be able to do simple triangulation (assuming radar is working). Of course, in the code, we wouldn't bother doing triangulation, we would already know the source and just either delay notifying the HUD/AI or do it immediately.

safemode wrote:Also, strength is handled intrinsically as your ship would automatically know the source of the weapon and be able to apply damage as a function of distance to that source without querying anything else. This can be handled with multiple sources in a system automatically.
Coding strength computation in the receiving side is backwards. The call should specify the exact strength and the receiving side only react.
[/quote]

the calling side has a "strength" ...as in energy level. But how much of it imparts to the shields, or hull or gets dissipated by some other means is up to the reciever. Also, if we are talking about a force, it's much easier to do the calculation of the magnitude of the energy at the reciever end than try to figure it out at the sender end, since with forces the magnitude of the force is dependent on distance. The sender is sending out a generic (point blank) level of energy in it's weapon fire and leaving it up to recievers that intersect with it to then look at how far away it is in order to reduce the magnitude of the energy based on distance.

Otherwise, the sender has to look at distance after it figures out an intersection has occurred, then send the appropriate energy level to the reciever. An extra unnecessary step.
Ed Sweetman endorses this message.
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Re: post release: What to do about nebulas

Post by chuck_starchaser »

safemode wrote:In this setup, the source of the effect is responsible for sending (attacking) a unit in the sphere of influence. So basically, your unit gets too close to something, it fires off it's radiation "weapon" at you and you start taking radiation damage. But really, all the source is doing is sending you a packet describing what the packet is, how much energy it has and where it came from.
That's a terrible idea, Safemode. Look what happens if we take your paradigm and back-port it to weapons: Just because I shoot at you doesn't mean my shots are going to hit you. In fact, I'm such a poor shot, probably more of my shots will hit my friends than will hit you. But if I send you a message at every shot, I will probably crash your computer :D
That's not how weapons work: Bolts have an existence of their own, and are under the management of the collision system. They can hit anything, and when the collision system detects a hit, it should inform both participants in the hit that they've hit/been hit by something, and what that is. The source of the shot is irrelevant, except maybe to the AI.
But if you make stars and planets "shoot gravitons at everybody", you are stepping down into an erroneous paradigm.
IOW, you're simply talking about a star messaging you that it's attracting you; NOT about anything even remotely related to how weapons work (or should work). And then, how often do you envision the star messaging you about its attraction? Once is enough. You see? The star can just tell you "I'm here", and that's enough for you to feel the gravity continuously until you leave the system. And you knew it was there, anyways, so why bother with text messages?

Besides, it is a completely unnecessary complication. There aren't that many sources of gravity in a system; --stars, planets and moons. That's it. Asteroids' gravity is miniscule; irrelevant.
So, for each unit you're considering gravity, just iterate through the dozen or so attractors adding their forces. Done!
And the code is already there.
And as far as other effects, like radiations at various wavelengths, or charged particles, they could piggy back on gravity; i.e. use the same or a similar system.

As far as the problem with stations and ships losing tracking, here's two ideas:
1) Orbiting stations could have precomputed circular orbits UNTIL the player approaches for a landing, at which point they can be simulated, and...
2) Use the same simulation atom as the player. And once you've landed, the station gets back to its predefined, circular orbit.

NOTE:
I believe this simulation atom thing is terribly implemented, and I intend to do something about it; namely,
these "atoms" (hate the name) should be power-of-two frames; the various power of two levels should be
interleaved in time, and each time-slot object should have a list of units to be iterated in that slot, rather
than iterate through all the units checking their atoms. Also, the way simulation rate levels is assigned
should be parametric and better thought out, and include hysteresis to avoid frequent switching; and should
ensure that units in the same area are synchronized. And the code should be simple, clear, and perform.

As far as local effects, I'd go with Klauss' affectors over messages any time. Affectors have a defined extent
in space, and manage the interactions within. Just like a collision system manages bolts after you fire them.
The affector can decide which interactions are important and which aren't.
If every unit has to message every other unit, you got an n^2 problem.
safemode
Developer
Developer
Posts: 2150
Joined: Mon Apr 23, 2007 1:17 am
Location: Pennsylvania
Contact:

Re: post release: What to do about nebulas

Post by safemode »

klauss wrote:Before addressing each point separately, I'll have to point out an overall shortcoming in the way you decided to model things.

You're modelling the solution by mimicking a model of the domain. While this is a way to handle some situations, it isn't necessarily the best thing to do. It doesn't even have to work.

One has to model the problem and the solution separately.

By your attempt to model the solution based on real life objects, you're imparting too much behavior to a single object class. This complicates the implementation of the solution immensely, mostly on a problem as difficult as simulating space dynamics at a star system scale.

The model I'm proposing separates a single real entity (the star) into multiple solution-domain entities: its visual appearance, its physical interaction with other units, its intelligence (none).

Separating the solution domain into these aspects makes it a lot easier to add or remove complexity from each independently. The visual representation of a star may grow more and more complex without even touching physics code. Perhaps not even recompile physics code.
separating subsystems does not require making them independent scripts. This can easily be done within a single Sun object that owns it's effects and appearances. The argument being made by you is that the system owns certain effects (be them visual or physical). You dont give any example of why the system has to own it above, only that they need to be independent, which can easily be done while the sun object retains ownership of everything that has to do with the sun.
safemode wrote: what we were describing was not simply passive though. It is an active interaction with other objects.

<snip>

static means unchanging. That would imply the scripted behavior is immutable. This may be relatively the case when you compare a Star's forces to a ship, but Star objects could be interacting with other Star objects. Those would be forces that interact and modify eachother. Gravity becomes altered in the system to instead of pointing to both object's centers, it would be to the center of gravity about which the stars are rotating. etc etc. These are no longer static objects or immutable forces.
If you're proposing to simulate the mutual attraction between planetary bodies, cease and desist. Scientific computing already has a hard time doing that because numerical precision issues destabilizes otherwise stable systems. You shouldn't even attempt to model orbital motion in that fashion, it's too complex.

The way I was thinking it was rather simple: "star A has a circular orbit around center C with radius Ra and phase shift Pa. Star B has a circular orbit around center C with radius Rb and phase shift Pb." That's scripted motion. That's stable. And simple. And to the point.

The same could apply to a lot of other gameplay objects, BTW. Comets, flares, coronal ejections, superflares.

This simplifies and optimizes simulations. Why apply an iterative simulation that requires extreme precision and careful implementation when a simple formula is known to exist, and even an approximation serves our needs?
i want both. I want scripted motion mimicking orbits like you suggest, but i also want the ability to have a smaller limited system with dynamic orbiting. It's switchable, but available to every unit (via the graviton object everything inherits). Why not?
safemode wrote:I think that although they have much in common, they ought to be something else. Stars can be a Star object, with all the features that stars have and Planets will be Planetoid objects ...with all their features... so there is no need to attempt to hack them. Units and Stars and Planetoids will inherit the graviton object, (although i dont believe in gravitons). The graviton object gives them the ability to impose gravity on other objects in the game regardless of type, though, it must be turned on to emit the force, otherwise static orbits are imposed or stationary positions imposed.
You're recognizing that objects have several aspects, but reject the idea of modelling the different aspects as different classes. This kind of makes sense when you are attempting to use the problem's model as a model for the solution - but it will result in a complexified solution.
I dont care if we do it in seperate classes. I care who owns (initiates and recieves) aspects of that object. I care because it is much faster to have the sun send something to a unit and that unit to react to it than to have the system watching units and checking each one of it's "sun" scripts to see if anything needs to be done and then do it.

think of it this way, do we have a shield script that has a list of every unit in the system attached and the system then every frame traverses this list to see if weapon fire or a collision has taken place within range of the shield field for each unit and then behave differently or do we allow the unit to handle this as needed? The effects of a star or else wouldbe the same. it's not like the entire system is effected by this one uniform energy (which would make what you suggest with effectors make more sense) ...units can be blocked by planets from the effects, blocked by large asteroids, blocked by other units even. etc etc. Rather than having the system handling it, we have only the objects involved handled it.
Careful one-to-one mapping between effects and entities isn't required in a game. If I receive damage, I have to know where the damage comes, but the game does not. Not with exact precision - the AI is happy to know only that the damage comes from a dangerous area (an affector) to stay away from it. It doesn't care that the area is related to the star... nope.
where do we apply damage then? random? no. So lets say we give our weapon fire (or force or whatever is causing damage) a vector with no actual source unit referenced. How is it we can't triangulate where it's coming from? this isn't the 1800's. it would be expected that we would know where the source to something is for something as mundane as radiation or heat unless our instruments are malfunctioning.
Modelling the solution separately from the problem acknowledges that we don't have to model every bit of detail of the problem... only the bits we want to resolve. In this case, we want to portray believable reactions on the screen and that's it. So some details can be left out or rearranged to suit our needs. In this particular case, our need to split the complex problem in separate, less complex ones.
Modelling only what we need is one thing. but that isn't limited to what is on screen for the player. You seem to think so, but I would see every ship as a player. we may have LOD's for modelling things for non-human players but this does not require that you divorce the source from the effect. Doing so means you have to keep track of both. I'd prefer to just keep track of the 1 and let it handle everything it owns.
safemode wrote:Rather, i would consider creating these forces without an object emitting these forces being the same object that emits the force and takes up the space that represents the star to be a hack. And it would require much more coding to fake the presence of the star within some other layer (system i guess) rather than just having the object exist and do what it has to do.
I believe you are wrong. It will take less coding, for the code will be by far more straightforward:

Code: Select all

// Apply gravitational forces
for (UnitIter unit=units.begin(); unit != units.end(); ++unit) {
   for (GravIter grav=gravitationalAffectors.begin(); grav != gravitationalAffectors.end(); ++grav) {
      if (grav->unitInside(*unit))
         unit->applyAcceleration(blah);
   }
}
(Of course it's pseudocode and I'd like to unify affectors and have more efficient spatial culling structures, but more on that later)
dude. when are you supposed to run that crazy ass nested loop ? Every frame is when. How do you know if units in your list you just modified acceleration to have even had a physics frame yet when you next run your loop? flags? ugly.

Much more elegant to just have gravity get handled as each unit gets a physics frame, if it even has recieved a gravity hit as it needs to. No need to run through every unit, then every gravity field. every frame, passing over units that get nothing done to them along with gravity fields where no units may be occupying or units you already modified but haven't had a chance to do anything yet.

If press the button to shoot my laser, is it more efficient for this to do nothing but then every frame the laserfire_effector traverses the laser effector list (every unit with a laser registers one) and then traverse the unit list looking for units within the bounds of each laser_effector_field after checking if that particular laser effector field is active and then apply the laser hit to each unit ...or should i just have the button press shoot my laser and check if a unit is in front of it for a certain distance and if so, apply the laser hit to that unit ?

it's the same type of problem. I believe it costs more by having these types of effects owned by the system rather than by the units that do the effecting.
safemode wrote:objects dont cease to take up space in a system just because the player isn't there.
Again trying to force the real world's model into the solution yield suboptimal solutions.

Of course the object doesn't cease to take up space, but the computer (the simulation) ceases to care about it. So it doesn't have to have a full-blown instance in memory, only a summed up representation (position, orientation).

Your solution doesn't scale as well to millions of units because it refuses to prioritize the simulation according to the perceived effect. Tracking all the attributes of an asteroid that isn't near any ship may be correct, but not doing so looses little, and gains a lot of cpu cycles and memory bytes.

This relates to spatial culling, and why it's beneficial to separate the roles of a conceptual unit when possible and simulate them rather independently. A unit may be very very important all the time. Say a foe, you can't stop simulating a foe, it will chase you, it will think all the time, and the user will notice if it ceases to do so.

But you don't have to render it all the time. You could free the resources needed for rendering it if, say, it's lightyears away.

Same with an asteroid. You have to track its position all the time (well... not nearly so, you could have randomized fields), because you have to know when to draw it, and that depends on the proximity to the camera, which in turn depends on its position. So you can't discard position. But there's a lot of other stuff you don't need to have all the time. You don't have to track its orientation, perhaps, because if it's rotating, the minute the player leaves its vicinity he/she won't notice discrepancies in rotational evolution.

You don't have to keep the textures in memory either. Or the mesh. Or even have a variable anywhere telling you which mesh to use, because every asteroid in the field will have the same mesh.
we already prioritize simulation, but you seem to feel that the other ships in the game dont need to play the same game. While this could be true for many of them, eventually we'll have persistent characters that are AI that need to be treated in much the same way as the real player. We already do things like simulation LOD, and we already do graphics culling at a distance. Maybe this can be improved, but saying your method scales to millions of units is misleading at best. You're removing units you feel you dont need to have anymore leaving an index so you can recreate the unit if it's needed again. VS supports tens of thousands of units now, but try having more than a few dozen nearbye doing anything. The rest are already LOD'd on every level you mention, just maybe not with the granularity you are thinking of.


What i was suggesting was using this LOD'ing we do but not taking it to the extreme you do but instead keeping spatial simulation of inanimate objects somewhat intact. along with significant units to a certain degree. Mostly because i want to see persistent characters in the game....and not just specially scripted ones either. dynamic ones that become familiar throughout the game ... but yes, this can be approximated, but it's important that the ai is not simple reduced to a place-holder that gets re-created when needed. AI must be persistent, so should the unit's state (damage and such).
You don't have to keep track of every aspect of every unit all the time. Now take affectors.

You don't care for affectors of any kind if you're not within their area of influence, so I'd like a structure that can quickly give me a list of affectors containing a point in space - so when I'm simulating a unit, I can iterate those affectors only. That allows me to have many many affectors in the system, because the engine only processes the ones that actually do something.
really. you want every point within the range of an effector to be mapped and attached to what would amount to an interrupt handler ? This gets called _every_ time a unit is simulated. This is more elegant than just shooting a unit within range when we're simulated where "we" is the unit doing the shooting?

i dont get how you can see that as being more efficient.
Ed Sweetman endorses this message.
safemode
Developer
Developer
Posts: 2150
Joined: Mon Apr 23, 2007 1:17 am
Location: Pennsylvania
Contact:

Re: post release: What to do about nebulas

Post by safemode »

by message, i'm talking about the data within the bolt for instance. All the information is in the object that is the bolt. There's no text messaging going back and forth....no feed back from the victim to the attacker. The attacker encodes what he needs to in the bolt, and sends it off. It hits a unit and the unit reads the data in the bolt. done.

gravity is special, technically gravity has no limits, so in this case, the unit need only look at various significant units and add up the force and go on.... no need for anything there really. The graviton object was intended to flag what cares about gravity and when. Ie, when we're scripting gravity vs simulating it ..and what actually puts out gravity. You can't just use a significant unit list, but within our significant units are the units that do put it out. namely planets and stars (though everyone is arguing to not make planets and stars a unit like ships and bases are)... anyway, so we check the graviton to see if it is active.

In addition to this. the graviton can remain active in the case where we LOD unload the rest of the object, so our solar system doesn't fall apart. This graviton would not only work for simulated gravity but scripted as well, keeping the actual position and vector of an object if it's LOD'd away regardless of unit type.

Basically, think of the graviton as taking the place of the "unit" class. it's a common object that contains things a physical object has, like mass, vector, and gravity state.


when i was talking about shooting gravity at units, i was thinking of using gravity more in a very limited subtext. But that doesn't make any sense.



But if you want to use the idea of the bolt, the bolt owns it's collider. This is it's effector. The collision system doesn't run independently of the unit that's being simulated. The unit moves, it checks if it hit anything, so on. Not, the unit moves, another unit moves .etc... now check if anything hit anything.

I'm arguing for making forces (to be specific, Em related forces, not gravity anymore) more like a bolt.
Ed Sweetman endorses this message.
klauss
Elite
Elite
Posts: 7243
Joined: Mon Apr 18, 2005 2:40 pm
Location: LS87, Buenos Aires, República Argentina

Re: post release: What to do about nebulas

Post by klauss »

This is pointless.

For one, you're not getting the effector idea the tiniest bit.

For two, you refuse to.

For three, you're proposing very similar stuff (only twisted a bit), and saying it's orders of magnitude more efficient. The difference isn't that big... you're not getting the idea.

When you say effectors are wrong... well... they're not. The nested loop runs hot. I've implemented a concept check already that simulates about 1 million repulsive particles (equivalent to 1 million effectors, effecting on each other), that runs at 40FPS on a pentium 4 1.7Ghz.

All I'm going to say is, the trick is data structures. Your way doesn't separate data enough to implement efficient data structures that allow that kind of performance - or at least I don't see how they do. My way is essentially the same, heck effectors are objects that don't behave like units, but rather send messages to units. It's your idea pretty much - only structured in a more flexible way. The gain is whereas your design unifies too much, structures too much, and allows too much dynamism, forcing an n² algorithm or complex hacks to get better performance, the flat design of effectors (they're not owned, they're not dynamic) simplifies and enables an n log n algorithm.

So... lets stop arguing like kids: "this is fast, this is better" - "no it's not" - "it is too" - " no is not"

Let us both implement our system, and make them contend. I won't have nearly enough free time for it, so I expect yours a lot sooner than mine. But I'll get an effector branch eventually, and we'll compare.

It's not wasting time, before you cry foul, it's a better way of reaching consensus than arguing about performance of a nonexistent implementation.
Oíd mortales, el grito sagrado...
Call me "Menes, lord of Cats"
Wing Commander Universe
safemode
Developer
Developer
Posts: 2150
Joined: Mon Apr 23, 2007 1:17 am
Location: Pennsylvania
Contact:

Re: post release: What to do about nebulas

Post by safemode »

really i dont see this getting implemented at all anytime soon. It's just brainstorming at this point.

The only thing i intended to hope to get cleared up and actually implemented soon (right after release) was nebulas.

nebulas being the effect of instrument fuzzing and omni-directional damage inducing radiation/heat at a system wide level.

basically,adding a couple variables to the system class and adding a check in the Unit's physics code-path to check for those variables and implement appropriate damage.

We can even create some special backgrounds to make it more obvious that the system is special and exists inside a nebula.

That's _all_ i intended to actually implement. The rest is thinking out loud and I dont think either one of the ideas should be attempted anytime soon.

I'm actually against rewriting anything more to the game without finishing the documentation of it. I dont care if we're documenting something we can see is obviously wrong and broken and are surely to replace as soon as we do the next release... it should all get documented. We dont want to get into a situation where we think we understand something, replace it only to find out down the road that things were done the way they were before for some particular reason that we are now butting up against with the new implementation ...etc etc. Even when no downside is possible, the offending code should be documented prior to modification if for no reason other than to understand why it's being replaced and what it is that's being replaced. This has to be done in the code, not in some forum.

I really believe this is a necessity of the highest importance...higher than incremental updates, higher than fixing Unit and even higher than fixing gcc warnings.

edit: and the only idea i'm actually happy at the moment enough with to actually want to see made happen is the removal of Unit as the base class of all things in the game and the graviton take it's place. Containing the location and vector and mass information of it's descendant object (ship, planet etc), it can act as the common object for lists, and other code that have to do with physical transforms. Allowing the complexity involved with higher level objects to be dis-included from such low level operations that dont care if you're a ship, an asteroid or a planet or missile. Plus, graviton just sounds cooler. And in anticipation that some things will no longer be based off of Unit, Unit obviously can't be the common object referenced by lists and such that would need to traverse all the new types. Gravitons, while i dont believe in them physically existing, would exist in everything so it makes more logical sense. :)
Ed Sweetman endorses this message.
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Re: post release: What to do about nebulas

Post by chuck_starchaser »

Frankly, I'd be happier yet to see Unit and and all types, functions, variables and comments containing a substring "Unit" or "unit" surgically removed from all the code (can grep do it?); --UNLESS they refer to grams, meters, seconds, or other such units.
Bad terminology begets bad code.

Case in point: Here we are, arguing about what the base unit should be, when we don't even know what "Unit" should mean... ALL we got to go by is what it presently does, in the code; and all we seem to agree about it is that it does the wrong thing; so we have no guidence whatsoever:
  • No clear intent or purpose from the class name.
  • No comments to explain what unit should represent, exactly
  • No "working definition" either, since the vote of non-confidence about how it works seems to be unanimous.
And, by the same token, safemode, "graviton" is an equivalent disaster. You've been unable to get it through my head (admittedly somewhat thick) what the hell your graviton is or does. And I'm sure you admit it doesn't model the theorized particle of its namesake.
So, this is it: You absolutely CAN'T use such a name. It is as confusing as anything could be. The best piece of code in the universe would be a piece of garbage with a name that means little to anybody; and that to the few it means something, it means the wrong thing.
Reminds me of ATOM, which in the vs engine has no mass, and measures time... :roll:
That's a COMPLETE no-no.

(("Attractor" perhaps?
And if so, why should "attractor" be THE base class?
That would imply that nav points and jump gates ARE attractors, which they aren't.))
safemode wrote:The unit moves, it checks if it hit anything, so on. Not, the unit moves, another unit moves .etc... now check if anything hit anything.
I just hope you are exactly wrong...
If we're really doing what you say, we should throw this engine to the garbage and start anew.
Processing interactions intermixed with consequences is the most basic violation in simulation code.
That's a recipe for aliasing bugs.
Forces and accelerations and delta velocities should be processed for all.
THEN motions should be processed for all.
THEN collisions should be processed for all.
Separate sub-frames.

And by the way, if we're using Euler, we should NOT; we should use RK4.
http://gafferongames.com/game-physics/i ... on-basics/
safemode
Developer
Developer
Posts: 2150
Joined: Mon Apr 23, 2007 1:17 am
Location: Pennsylvania
Contact:

Re: post release: What to do about nebulas

Post by safemode »

atom refers to indivisible, aka smallest unit. If you are familiar with anything in programming, you would be familiar with the term atomic. As in, an atomic operation.. It has nothing to do with the physics term, atom, in the sense that it refers to a group of subatomic particles that have a net neutral charge etc etc.

The simulation atom is similar in meaning to an atomic operation, in that it is the smallest unit, but this unit references dynamic real time.

Just because you dont understand it, doesn't make it wrong. Just because it's not spelled out like a java function, doesn't make it wrong either. I have no problem at all seeing the word simulation atom and knowing that it is it's term for a unit of time ... no different than a jiffy in the linux kernel.

similarly, a unit is an object that can be manipulated and interact in the game. Now, how unit is implemented currently is wrong, and the result of a decade+ of lazy hacking. But saying that the word is somehow cursed to only referring to the mathematical term is narrow minded. Units are referred to manipulated objects in numerous games and even end users are walking around wondering what these "units" are referring to in games like warcraft, starcraft etc.

there is a limit to being pedantic about names. I name a counter "i", not because it's more descriptive than naming every counter some simile of "counter" but because it's faster to just type i and it's context is easily understood regardless of what it's called.

The problem in VS code is that sometimes the context is not easily understood. This is a problem with the structure and lack of documentation, not the names of things.

Dont get hung up on silly things like names. When it comes to unit, it's got much more important problems....what you call it is the last of them. But leave that crap until after we make the next release.. nobody is doubting that it's an entire mess.


As for graviton, i explained what the graviton does. It acts as the base unit that all units that get physically manipulated inherit. It holds the variables for mass, velocity (vector velocity), position, and if simulated gravity is enabled or not. That's it. Physics need only operate on it when doing transforms. By unit, i refer to all objects in the game that move, and occupy space in the game and have mass. This is not the same "unit" as we currently know and love, but to whatever idealized classes you can imagine that refer to things like planets, suns, ships, turrets, missiles, bases , asteroids, etc.
Ed Sweetman endorses this message.
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Re: post release: What to do about nebulas

Post by chuck_starchaser »

safemode wrote:atom refers to indivisible,
And is the "SIMULATION ATOM" indivisible? No; it isn't.
aka smallest unit.
Is it the smallest unit? No it isn't. (And a common technique we might soon implement, for elastic bounce, is to subdivide the simulation into smaller steps when a collision is detected to compute bounces correctly; rendering the name downright contradictorily misleading.)
If you are familiar with anything in programming, you would be familiar with the term atomic. As in, an atomic operation.
If you're familiar with anything in programming, you'd be familiar with the term atomic, which means during which a thread cannot be interrupted by another; or a function cannot be reentered; which SIMULATION ATOM is not; and which is yet another way the term is misleading to a programmer.
The simulation atom is similar in meaning to an atomic operation, in that it is the smallest unit, but this unit references dynamic real time.
Ergo, is neither indivisible nor smallest; it varies in size.
Just because you dont understand it, doesn't make it wrong.
The fact that it's misleading makes it wrong.
Just because it's not spelled out like a java function, doesn't make it wrong either.
I don't program in java; so I cannot comment.
I have no problem at all seeing the word simulation atom and knowing that it is it's term for a unit of time ...
Programming itself has a problem with meaningless terms; and a bigger problem with misleading terms.
no different than a jiffy in the linux kernel.
Jiffy is meaningless, and so it is a bad choice of a term; but not as bad as a misleading term.
similarly, a unit is an object that can be manipulated and interact in the game.
Note your use of the word "and". "Manipulated AND interacted." So a jump point is not a unit?; or it is but it shouldn't be? Because it can be interacted with, by pressing J, but it cannot be manipulated; so it doesn't pass your x AND y definition; or did you mean x OR y? That's precisely the problem: you're trying to define what it means NOW, years after it was coded, and you probably won't succeed at defining it exactly.
Now, is the meaning of "unit" in real life "something that can be manipulated and interacted with"? If not, then how does calling it "unit" help the programmer know what the hell is meant for it to do or to be?
Now, how unit is implemented currently is wrong, and the result of a decade+ of lazy hacking.
of a decade of lazy hacking without any guidance as to what was the intent for the class, with a name as ambiguous as anyone could have come up with.
But saying that the word is somehow cursed to only referring to the mathematical term is narrow minded.
The word is cursed in real life. It has, over time, become a monstrosity, thanks to generation after generation of misusing the term until nobody knows what it means anymore. In the beginning "unit" was always "a unit of" something, --be it a unit of measure, as per my previous post's example; or a "unit of purpose", or the minimum number of something you can count. Then came corrupt uses of the word, such as in miltaries that call a group of soldiers on a mission a "unit", I supposed with the intent to mean that they (should?) "work as a unit" (meaning, as a single soldier?). And of course, at a "TV set" (yet another oxymoron) manufacturing plant, each "TV set" is referred to as a "unit" being shipped.
But in spite of various, and somewhat contradictory and corrupt uses of the term, you can still educe a common thread.
Now we come to the use of "unit" in the vs engine, and neither legitimate nor corrupt uses of the term from real life have any semblance to its "working definition": The kinds of things that can inherit "Unit" are so different and various, there's no way to tell these were meant to be units of what? Not to speak of "sub-unit" (another oxymoron)... A gun turret can be manipulated with AND interacted with (and in PU they even talk to you...); and yet they are classed as "sub-units". The term "sub-unit", not only appears to contradict the "unity" of "unit", but it is misleading in its own right: You would think it is like a part, or constituent, when in reality it is an attachment.

But it's not ME that has a problem with badly chosen terms in programming; it is every self-respecting programmer that does; is is programming itself, as pursuit, art and passion.
Programming is challenging, hard, error-prone; and the last thing you want to do is make things worse by being lazy about thinking what's best to call something, so that it will be obvious and clear as to what it is meant to do.
What would have been so wrong about calling it "GameObject"?
Units are referred to manipulated objects in numerous games and even end users are walking around wondering what these "units" are referring to in games like warcraft, starcraft etc.
Well, in Starcraft, a "unit" is A soldier, for example; ONE soldier; and in that sense it is "a unit of infantry". That is nowhere nearly as wrong as what vegastrike calls "unit".
Using Starcraft as an example, what vegastrike does is as if Starcraft were to call (class) "soldier" a class of type "unit", which is completely meaningless and wrong.
there is a limit to being pedantic about names
Never heard of such a limit; but if there is, I'm sure I'm nowhere near it.
I name a counter "i", not because it's more descriptive than naming every counter some simile of "counter" but because it's faster to just type i and it's context
you mean its context? Am I being pedantic?
is easily understood regardless of what it's called.
You just don't get it. What it's called IS important. Using i for a counter is okay NOT because what it's called doesn't matter, but because i and j are well understood to be counter variables in programmers' lingo; so they are quite clear. If you were to use z as a counter, it would be BAD programming, because most programmers would tend to think it refers to a position in an axis.
The problem in VS code is that sometimes the context is not easily understood. This is a problem with the structure and lack of documentation, not the names of things.
It is because of lack of documentation secondarily; but because of the names of things primarily. A program where things are named carefully is usually self-documenting, and you hardly need to write any comments.
Dont get hung up on silly things like names.
Names are NOT "silly things". The vs engine is inscrutable precisely because the original coders thought. just like you do, that names are "silly things".
This is no different from what some engineers in the field of electronics do, who think that schematic diagrams are "silly things" --just a means to produce a circuit board. So they get a prototype assembled much faster than the better engineers; but then they spend months debugging their designs, because the schematic diagram is inscrutable.
Similarly, programmers of your philosopy think that sources are "just a means to an end", namely to produce an executable; and can't grasp the concept that sources are "documents"; that they are meant to make code ***clear***, so that it can be read and maintained.
When it comes to unit, it's got much more important problems....what you call it is the last of them.
No; it is precisely the first. All the other problems came after, and are the consequences of the first. The purpose of "unit" not being self-evident, anything went into it.
As for graviton, i explained what the graviton does. It acts as the base unit that all units that get physically manipulated inherit.
That's what "unit" does right now; and its name is somewhat more clear than "graviton"... So, all you want to do is change the name, to make it even more inscrutable?
It holds the variables for mass, velocity (vector velocity), position,
What's wrong with "PhysicalObject", then?
and if simulated gravity is enabled or not. That's it. Physics need only operate on it when doing transforms. By unit, i refer to all objects in the game that move, and occupy space in the game and have mass. This is not the same "unit" as we currently know and love, but to whatever idealized classes you can imagine that refer to things like planets, suns, ships, turrets, missiles, bases , asteroids, etc.
So, instead of writing paragraph after paragraph, post after post, explaining your "graviton"; why not just call it "PhysicsObject" and let its purpose be obvious? Can't you see the practical value of proper names? Time is money. You wasted hours of my time, and wasted hours of your own time, for what reason? Just because you like the term "graviton" and want to use it no matter what?

It's as if we were arguing about cars and I consistently used the word "springs" to mean "shocks", and "shocks" to mean "springs", confusing the hell out of you, and once you figure out the problem and raise an issue with it I were to call you silly and pedantic for giving a damn what the exact names of these things are.
Hey, I don't like names any more than you do; but we've got a language; let's use it.
The name "PhysicsObject" applied to a class that contains position, mass and velocity, doesn't even need a one-line comment explaining what it is. It is obvious even to a non-programmer.
How or why you would have come up with a term as bad as "Graviton" for it is what I find baffling. There must be a genetic trait that makes some people seek clarity, and makes others pursue confusion and obscurity.

Or do you work in marketing?
Because, frankly, there's nothing new, at all, about having a class PhysicsObject that has mass, position and velocity, and is the base class for all physical object classes. Absolutely nothing new about it, except for the (pretentious) name "Graviton". Seems like trying to push a new and silly buzzword.

And it would be better for it to be programmed as a template trait:

Code: Select all

template < class Derived, typename T >
class PhysicalObject : protected AbstractPhysicalState<T>
{
    void check_invariants(); //throw
public:
    void SimulationStep( milliseconds time );
};
//where,
template < class AbstractState >
class SimPhysicalState
{
    AbstractPhysicalState a, b; //a and be can be either current or previous-next; and swap roles before each step
    mutable AbstractPhysicalState *prevnext; //in a PhysicsStep processing, next state overwrites previous, while...
    mutable AbstractPhysicalState *current; //...current remains read-only and read-accessible to other threads
    void flipPrevnextAndCurrent();
    virtual PhysicalStep_( milliseconds time );
public:
    void PhysicalStep( milliseconds time )
    {
        flipPrevnextAndCurrent();
        PhysicalStep_( time );
    }
    AbstractPhysicalState const & currentState() const { return *current; } //reentrant and thread-safe
    AbstractPhysicalState       & prevnextState()      { return *previous; }
};
//where
class AbstractPhysicalState
{
public:
    virtual ~AbstractPhysicalState() = 0;
    .........
};
template < typename Precision > //e.g. float, double
class SpringPhysicalState : public AbstractPhysicalState
{
    ...............
};
template < typename Precision > //e.g. float, double
class InertialPhysicalState : public AbstractPhysicalState
{
    typedef vec3<Precision> vec3_t;
    typedef Precision scalar_T;
    vec3_t position;
    vec3_t momentum;
    vec3_t velocity;
    scalar_t mass;
    scalar_t inverse_mass;
    milliseconds time_stamp;
};
//alignments notwithstanding; in fact, where
template < typename Precision >
class vec3
{
    typedef Precision scalar_t;
    scalar_t x, y, z;
    scalar_t __padding__; //for proper alignment
public:
    ...........
};
I hope you understand that "Unit", the way we understand it [:D], may need one PhysicsObject-derived object PER moving part...
I hope you ALSO understand that the code I wrote above is not only incomplete (lacks orientation quaternion, tensor of inertia and torque and torque axis, as well as a forces accumulator, and various odds and ends), but is is also limited to weights.
Springs need a different set of data, as they use positions as inputs, and output forces.
So, what you called Graviton, and I renamed to PhysicsObject, should really be called WeightObject or MassObject.
And most physical objects need one or more weights and zero or more springs, as well as pivot points with axes and motion limits.
So I'm not sure about the wisdom of deriving GameObject from MassObject. It should really derive from PhysicalSystem, which may boil down to a single MassObject in the simplest case (as currently covered).

You see now how names are not "silly things"?
The act of looking for better names has just led me to the realization that my class system was not general enough.
And when you design a class system that is not general enough, later you're stuck with having to refactor it, which is a lot harder to do than to design a class system properly from the get go.
safemode
Developer
Developer
Posts: 2150
Joined: Mon Apr 23, 2007 1:17 am
Location: Pennsylvania
Contact:

Re: post release: What to do about nebulas

Post by safemode »

i'm not fighting that we should call whatever the replacement for unit is a graviton, but just that the idea of it should be what replaces it. I named it on the fly. I really dont care what it's named.

As for your templated code, I would not try and be too flexible to the point you're supporting features we dont have and wont have....it ends up becoming dead code and dead code is obfuscating code whether it's clear or not. Things like springs i dont think will have any place in the game.

but i'm not so sure about templating it. It seems more like a property that effects the makeup of things than a shared property among variants.

is it ever going to be recieving different datatypes to operate on? no. mass will always be the same datatype, velocity will be the same, whether we simulate gravity will be the same. These variables would not change per unit class type if we end up creating multiple types. So a template here doesn't make much sense unless we aim to avoid inheritance throughout the unit object for no other reason except to avoid vtables

a template should be a shared structure of operation that receive different types to operate on per templated class you have. That would not be the case with this physicalObject class. A ship will not have double typed mass while a planet int type. A ship would not have float velocity while a base double type. etc etc. And if you dont need that kind of feature, why make it a template?

ps. This is a brain game, none of it is wasted time...
Ed Sweetman endorses this message.
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Re: post release: What to do about nebulas

Post by chuck_starchaser »

safemode wrote:i'm not fighting that we should call whatever the replacement for unit is a graviton, but just that the idea of it should be what replaces it. I named it on the fly. I really dont care what it's named.
Good!
As for your templated code, I would not try and be too flexible to the point you're supporting features we dont have and wont have....it ends up becoming dead code and dead code is obfuscating code whether it's clear or not. Things like springs i dont think will have any place in the game.
I would suggest we've needed springs for a long time. I can, for instance, fly slowly inside a station, towards a wall, and the moment a wing-tip touches the wall my ship explodes. Why? Because the only sane way to deal with collisions is having a spring at the point of collision. Anything else is a hack. This doesn't mean we have to carry weights and springs wherever we go, and simulate them all the time; but the moment a collision is detected we could simply spawn a temporary spring. Problem solved.
PU has been waiting for springs for a long time. I would like to spring-mount turrets; specially on capital ships, so that when they fire you can see not only the cannons snapping backwards (which could simply be a static animation), but even the whole turret oscillate back a little bit.
We were discussing this at the WCU forum many years ago.
but i'm not so sure about templating it. It seems more like a property that effects the makeup of things than a shared property among variants.

is it ever going to be recieving different datatypes to operate on? no. mass will always be the same datatype, velocity will be the same, whether we simulate gravity will be the same. These variables would not change per unit class type if we end up creating multiple types. So a template here doesn't make much sense unless we aim to avoid inheritance throughout the unit object for no other reason except to avoid vtables
There's a lot more advantages to templates than the static polymorphism idiom (Curiously Recurring Template Pattern); their mere presence sometimes makes the compiler generate more efficient code, --such as ignoring unused code, or reusing code for different template types whenever it doesn't differ from the code for another template type; which as the programmer you might not realize is the case. But in any case, I wrote that code off the top of my head, as a quick example how the physics could be structured.
I was thinking that we may have some use for the Barton Nackman trick; --check the example, if you're not familiar, and replace "equal_comparable" with "simulatable", "collidable", etceteras.
But yes; avoiding vtables is a genuine pursuit, with great rewards.
I also think, though I'm not sure, the compiler may optimize away vtables if you make all base classes Abstract, and leave their pure virtual functions unimplemented (which precludes making the dtor pure virtual, as the dtor must be implemented anyhow); but I'm not sure; I don't remember where I read this. Or maybe it was when there's no virtual functions at all; --they are either pure virtual or non-virtual.
a template should be a shared structure of operation that receive different types to operate on per templated class you have. That would not be the case with this physicalObject class. A ship will not have double typed mass while a planet int type. A ship would not have float velocity while a base double type. etc etc. And if you dont need that kind of feature, why make it a template?
True; the only member that could use type variance is position (float or double); the rest would be just floats.
Right now, position is always a vector of doubles; but I've been thinking for a long time that there should be local coordinate systems using floats; but that's a long story; and it's always easy to change a non-template class to a template class, anyways.
klauss
Elite
Elite
Posts: 7243
Joined: Mon Apr 18, 2005 2:40 pm
Location: LS87, Buenos Aires, República Argentina

Re: post release: What to do about nebulas

Post by klauss »

safemode wrote:The simulation atom is similar in meaning to an atomic operation, in that it is the smallest unit, but this unit references dynamic real time.
As chuck said, it's not.

Let me point you to the ogg spec for a list of mistakes not to make: objections to Ogg

Basically, the ogg specification has a lot of problems, but of them one of the stupidest if you ask me is that of inventing terms for things that were commonly known by another name in the industry. It simply misleads and confuses implementors. A bad thing.

So... the simulation time step (there's the name) has a name already, throughout the industry. It's the time step. Simulation step. timestep. Etc... and variations thereof.

So: find -iname '*.cpp' -exec sed -i 's/SIMULATION_ATOM/SIMULATION_STEP/g' {} +

DISCLAIMER: execute that line with care. I take no responsability if... for instance... it formats all your drives :-p
safemode wrote:no different than a jiffy in the linux kernel.
Very different.
A jiffy is ~1/18th of a second.
The kernel uses a jiffy because it was the smallest accurately measurable unit of time in older architectures, by tapping into irq 0 (IIRC).
safemode wrote:similarly, a unit is an object that can be manipulated and interact in the game.
In which way?
VS' unit's problem isn't its name. Its name is OK. It's the huge amount of behavior enclosed in a single class. "Unit" means a helluva lot in VS. It shouldn't.

As chuck said, some code wants units so it can get their position and size.

Some other code wants to apply damage to a unit.

Some other code wants to talk to a unit.

There you have 3 separate aspects of a unit, all encompased under the all-encompasing "Unit" name. I like "PhysicalObject" a lot more, but still it's the wrong name perhaps.

The first thing we need to agree if we're going to replace VS' unit class hierarchy is what's the lowest common denomination behavior for game units. What kind of stuff does every unit have to be capable of?

Is the "personality of a unit" really necessary for all units? I'd say no, asteroids and other non-thinking units shouldn't have a personality.

Is the "physical aspect" of a unit really basic? Perhaps, perhaps not. Suppose I want to model nav points as units... nav points don't have a physical existence. Be we could decide to overlook that, and say that some physical objects don't "occupy space" while others do... since I do believe all units have a location, velocity and size. That seems physical enough.

So... the problem with Unit is that it means too much. I've been saying it all along. We have to cut it to pieces, and for a basic name, I don't dislike "Unit". "PhysicalObject" is more to the point, though, as would be "IntelligentObject" and so and so...

BTW, chuck, you're thinking in Java terms even if you don't program in Java. "PhysicalObject" wouldn't be a class, it would be an interface, same as IntelligentObject, and concrete unit classes would implement several interfaces.

C++ doesn't have that, so beware... mapping that kind of thinking into C++ may be troublesome. Multiple inheritance, for instance, is one way, and it is not without trouble.
safemode wrote:The problem in VS code is that sometimes the context is not easily understood. This is a problem with the structure and lack of documentation, not the names of things.
Well said.
It may or may not be the problem but it is indeed a big problem.
safemode wrote:Dont get hung up on silly things like names.
Well... just don't overestimate names. They're important, only perhaps not the most important thing.
Oíd mortales, el grito sagrado...
Call me "Menes, lord of Cats"
Wing Commander Universe
klauss
Elite
Elite
Posts: 7243
Joined: Mon Apr 18, 2005 2:40 pm
Location: LS87, Buenos Aires, República Argentina

Re: post release: What to do about nebulas

Post by klauss »

chuck_starchaser wrote:I would suggest we've needed springs for a long time. I can, for instance, fly slowly inside a station, towards a wall, and the moment a wing-tip touches the wall my ship explodes. Why? Because the only sane way to deal with collisions is having a spring at the point of collision. Anything else is a hack.
Perhaps we should look into offloading some of that complex simulation that is required to some library, perhaps [url=http://www.ode.org/]ODE[/quote].
Problem is, I don't think those libraries fare well in big, largely interaction-less worlds as vegastrike's, they waste resources in those situations.
Good thing is, though, that you can use ODE's collision detection separately from ODE's system-solving part, but the integration wouldn't be trivial by far.
I do believe VS could use some of the complex features of such a library. Exploding ships make for really complex physical scenes, and ODE could handle them off-the-shelf. The hard part is identifying the interacting components and dynamically setting up the required ODE structures.
chuck_starchaser wrote:This doesn't mean we have to carry weights and springs wherever we go, and simulate them all the time; but the moment a collision is detected we could simply spawn a temporary spring. Problem solved.
Read ODE's documentation on how it works.
It's really complex, albeit very similar in principle to what you say.
Oíd mortales, el grito sagrado...
Call me "Menes, lord of Cats"
Wing Commander Universe
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Re: post release: What to do about nebulas

Post by chuck_starchaser »

Okay, I'm sold. Let's do it.
We're going to have to hack the heck out of ODE. It puts EVERYTHING in the stack, apparently; they say they are okay
in linux because it can allocate up to 100 megs for the stack, but windows needs to be told to allow that.
And I see nothing written about SIMD optimizations.
On the other hand, our physics are rather simple, anyways.
klauss
Elite
Elite
Posts: 7243
Joined: Mon Apr 18, 2005 2:40 pm
Location: LS87, Buenos Aires, República Argentina

Re: post release: What to do about nebulas

Post by klauss »

I don't think we'll have a problem even in windows land.

What it pushes into the stack are the problem matrices, which are N by M, with N being the number of constraints (which somewhat relates to the number of joints, which somewhat relates in turn with the number of collision pairs), and M being the number of objects, which if done right should be low for VS.

Matrices of 100x100 are already considered huge in terms of solution complexity, and use up little stack.

It's benchmarks and "show off" kind of programs that push the stack to the limit.

At least that's what I got from reading the docs a while ago.
Oíd mortales, el grito sagrado...
Call me "Menes, lord of Cats"
Wing Commander Universe
safemode
Developer
Developer
Posts: 2150
Joined: Mon Apr 23, 2007 1:17 am
Location: Pennsylvania
Contact:

Re: post release: What to do about nebulas

Post by safemode »

if you want to bench VS at it's most heavy, run total_war (modified to whatever number of units you want to test at) and profile that. I think you'll be surprised as to what the actual eaters of cpu are.. it's mostly not physics related. So if you are looking for vast speedups, i dont think you're likely to find it because we're fairly simple when it comes to physics. But if you want features we dont offer in physics land, then that would be different.

Either way, we should stress test VS so we have a baseline so any changes that go in after release can be compared against it.
Ed Sweetman endorses this message.
Deus Siddis
Elite
Elite
Posts: 1363
Joined: Sat Aug 04, 2007 3:42 pm

Re: post release: What to do about nebulas

Post by Deus Siddis »

What about Bullet? I'm certainly no expert, but isn't it supposed to be the better solution versus ODE at this point?

http://bulletphysics.org/wordpress/

My impression was newer, C++ based projects usually go with it, whenever they decide to go with a free physics engine.
klauss
Elite
Elite
Posts: 7243
Joined: Mon Apr 18, 2005 2:40 pm
Location: LS87, Buenos Aires, República Argentina

Re: post release: What to do about nebulas

Post by klauss »

There are probably also licensing issues that make commercial games favor bullet over ODE.

I've heared of that library, and have very good references, although I have no experience with it. It's certainly worth considering.
Oíd mortales, el grito sagrado...
Call me "Menes, lord of Cats"
Wing Commander Universe
safemode
Developer
Developer
Posts: 2150
Joined: Mon Apr 23, 2007 1:17 am
Location: Pennsylvania
Contact:

Re: post release: What to do about nebulas

Post by safemode »

opcode was chosen over bullet because bullet was not easily compatible

though, bullet does the same thing opcode does, only slower.

ODE would replace our physics subsystem, with opcode still doing the colliding because it's just faster than the open and free alternatives.

so you're referring to two different things there.
Ed Sweetman endorses this message.
safemode
Developer
Developer
Posts: 2150
Joined: Mon Apr 23, 2007 1:17 am
Location: Pennsylvania
Contact:

Re: post release: What to do about nebulas

Post by safemode »

safemode wrote:opcode was chosen over bullet because bullet was not easily compatible

though, bullet does the same thing opcode does, only slower.

ODE would replace our physics subsystem, with opcode still doing the colliding because it's just faster than the open and free alternatives.

so you're referring to two different things there.

ps. moving to a new physics subsystem that can handle nifty effects like explosions and such isn't a bad idea, but not one that would happen soon. Replacing the collider with bullet or the like though, is a waste of time at the moment. The only thing that would require it would be needing to deal with colliding with dynamic meshes (meshes that bend and warp)...which we dont have and wont have anytime soon.
Ed Sweetman endorses this message.
klauss
Elite
Elite
Posts: 7243
Joined: Mon Apr 18, 2005 2:40 pm
Location: LS87, Buenos Aires, República Argentina

Re: post release: What to do about nebulas

Post by klauss »

safemode wrote:ps. moving to a new physics subsystem that can handle nifty effects like explosions and such isn't a bad idea, but not one that would happen soon. Replacing the collider with bullet or the like though, is a waste of time at the moment. The only thing that would require it would be needing to deal with colliding with dynamic meshes (meshes that bend and warp)...which we dont have and wont have anytime soon.
I agree. In fact it was my point when I wrote that it wasn't a trivial matter.

But it's not only to handle nifty effects... it's also to offload development. Which is good when we're short on time and/or developers.

In that sense, maybe ODE's development is a little slow... bullet seems more actively developed. But if you've found compatibility issues...

I know ODE works well in all our supported platforms. And it integrates well with opcode, BTW. In fact there's an example of how to use opcode as collision library with ODE as dynamics solver.
Oíd mortales, el grito sagrado...
Call me "Menes, lord of Cats"
Wing Commander Universe
log0

Re: post release: What to do about nebulas

Post by log0 »

Hi,

First of all I am very happy to see vegastrike being actively developed. I've been following the recent discussions with great interest, especially the "Developer Focus" subforum showing the problems/challenges of working with an existing/old codebase.

There are some things I'd like to remark about the simulation aspect of vegastrike.

1. Selecting the appropriate model(of a certain natural phenomenon)
Lets have a look at the gravity. You could do it the hard way and set up a n-body simulation. Then you have to deal with things like the numerical stability(energy conservation).
But taking the huge mass of the sun 99.98% of the whole system and the distances between the masses into account. You could get away with an planet rotating about a fixed sun approximation. In this case even a analytic solution exists(conic sections). Meaning that you will get more exact results than running the numerical simulation.

2. Collisions
You don't need to use a spring-mass model.

The most simple model is an elastic collision of two point masses m0, m1 imho.
(ui, vi velocities along collision normal)
v0 = (u0 * (m0 - m1) + 2 * m1 * u1) / (m0 + m1)
v1 = (u1 * (m1 - m0) + 2 * m0 * u0) / (m0 + m1)

Then you may want to add some plasticity(coefficient of restitution cr).
v0 = (u0 * (m0 - cr * m1) + (cr + 1) * m1 * u1) / (m0 + m1)
v1 = (u1 * (m1 - cr * m0) + (cr + 1) * m0 * u0) / (m0 + m1)
The cool thing here is that you could use the loss of kinetic energy to describe the amount of damage.
This way it would automatically depend on the masses, velocities, restitutions of the colliding objects.

To get more accurate behavior you need to switch to convex(one contact point) rigid bodies.
This is a bit more complicated as you have to take rotational inertia into account(i could post the code if someone is interested).

The next step would be a full blown rigid body simulation resolving multiple contacts per body.
Here I would seriously think about using one of the existing physics engines(bullet, ode).

3. "spring-mount turrets" or projectile weapons on space ships :)
A projectile weapon is essentially a propulsion system (actio est reactio).
So the space ship with turrets has to have an active stabilization system(turning on the thrusters keeping it in place).
Could look quite entertaining. But I think it is more realistic/straightforward to use propelled projectiles(missiles) here.

4. More realistic space
Any flight direction/speed change should be caused by using the appropriate thrusters(front/back, left/right, up/down).
Ship orientation should be decoupled from its current flight direction. To ease flight control one could add an automatic flight direction system(flight in the direction the cursor is pointing). But there should be some inertia at least depending on the trust of the engines, mass of the ship.
Ships should fly on orbits as space stations(actually all dynamic objects).
There is no ambient light in space except you are close to a lit surface/body. So it should be friggin dark with very high contrasts and sharp black shadows.
klauss
Elite
Elite
Posts: 7243
Joined: Mon Apr 18, 2005 2:40 pm
Location: LS87, Buenos Aires, República Argentina

Re: post release: What to do about nebulas

Post by klauss »

Hi... log0?

People already started working on your fourth point. It needs more artsy work than coding, though, which is the kind of work that demands the most time.
Oíd mortales, el grito sagrado...
Call me "Menes, lord of Cats"
Wing Commander Universe
safemode
Developer
Developer
Posts: 2150
Joined: Mon Apr 23, 2007 1:17 am
Location: Pennsylvania
Contact:

Re: post release: What to do about nebulas

Post by safemode »

klauss wrote:
safemode wrote:ps. moving to a new physics subsystem that can handle nifty effects like explosions and such isn't a bad idea, but not one that would happen soon. Replacing the collider with bullet or the like though, is a waste of time at the moment. The only thing that would require it would be needing to deal with colliding with dynamic meshes (meshes that bend and warp)...which we dont have and wont have anytime soon.
I agree. In fact it was my point when I wrote that it wasn't a trivial matter.

But it's not only to handle nifty effects... it's also to offload development. Which is good when we're short on time and/or developers.

In that sense, maybe ODE's development is a little slow... bullet seems more actively developed. But if you've found compatibility issues...

I know ODE works well in all our supported platforms. And it integrates well with opcode, BTW. In fact there's an example of how to use opcode as collision library with ODE as dynamics solver.
as far as i know, ode uses gimpact, by default, and opcode is a pluggable module ...as well as bullet which apparently has a niftier subset of features but is slow. Usually the comparisons are between gimpact and opcode, with opcode offering an older but faster subset of features with the idea that future development will make gimpact and bullet faster ... which as of yet, i dont think has occurred. Anything else you may find out there is likely to be patent encumbered.

Replacing our homebrew (actually it's mostly crystalspace, circa half a decade ago) physics code with ode isn't a bad idea, just something that would need to be tested for speed, because even though it takes the burden off of us to keep updating it, if it's not faster it's not worth the work until our current setup proves impossible to do something we really really want to do.
Ed Sweetman endorses this message.
Post Reply