post release: What to do about nebulas

Talk among developers, and propose and discuss general development planning/tackling/etc... feature in this forum.
safemode
Developer
Developer
Posts: 2150
Joined: Mon Apr 23, 2007 1:17 am
Location: Pennsylvania
Contact:

post release: What to do about nebulas

Post by safemode »

I think we can all agree that the way nebulas exist in the game currently is completely wrong. They're tiny, they're geometric glass like structures. They just dont look or behave like anything they're supposed to.

I'd like to see nebulas as a unit completely removed. Instead, i'd like to see a new set of data members added to the system class that can denote when a system exists inside a nebula (they're fricken huge) and some properties a given nebula may have. Some nebulas may be very dense with dust (almost no visible light in this system)... some nebulas maybe highly active causing all sorts of radiation... etc etc. For the most part, one would not see the color of a nebula being inside it and all, but we may decide to take artistic liberties and make such systems a bit foggy. In any case, i'd like to see nebulas moved to where they belong, as a super-system entity that modifies properties of a given system you are in rather than as a unit that serves no purpose.
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 think we can all agree that the way nebulas exist in the game currently is completely wrong. They're tiny, they're geometric glass like structures. They just dont look or behave like anything they're supposed to.

I'd like to see nebulas as a unit completely removed. Instead, i'd like to see a new set of data members added to the system class that can denote when a system exists inside a nebula (they're fricken huge) and some properties a given nebula may have. Some nebulas may be very dense with dust (almost no visible light in this system)... some nebulas maybe highly active causing all sorts of radiation... etc etc. For the most part, one would not see the color of a nebula being inside it and all, but we may decide to take artistic liberties and make such systems a bit foggy. In any case, i'd like to see nebulas moved to where they belong, as a super-system entity that modifies properties of a given system you are in rather than as a unit that serves no purpose.
Totally.
Being inside a nebula boils down to "space fog" of a few hundred light years of depth; so nothing within the system would look foggy; it would only affect how you see far (non-local) stars, which by definition can be implemented statically in the background, and in fact already is, excessively so; so nothing to do.

If we want "nebulas" for their eye-candy value, we could implement them around stations and asteroid mines. That is, we'd represent "the fog of human activity", which would in fact be a very real problem in a space age. Very hard to get rid of. Stations would be surrounded by clouds of dust, orbiting ship parts, and waste illegally dumped into space.
Last edited by chuck_starchaser on Tue Mar 02, 2010 11:19 pm, edited 1 time in total.
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 »

For the Ogre branch I had already added a fourth rendering layer, the background layer, which would have 3D constructs as nebulas and such.

The idea was to have a 3D environment that spans the lightyears of the navmap, and be rendered instead of the cube-map-like background. So, if you have several systems inside the same nebula, you'd see the nebula from different angles.

In the event of warp-like travel, the "galactic camera" would move smoothly in that coordinate space and convey the notion of FTL travel within the nebula.

I believe it was a realistic and artistically pleasant (and original) way of portraying nebulas. Plus, it's technically rather simple.

Dust clouds are another matter and require vastly more complex techniques.
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 »

That sounds fantastic; but also sounds like a lot of work.
But it would be great to have a model galaxy with a sprinkle of nebulas in 3D, and a few
million stars, and then produce all backgrounds from it.
I guess the background rendering would switch between cubemap and 3D when you travel
between systems using spec?
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 always thought there was a technical limitation to portraying such huge distances since the game doesn't just render and simulate what's around the player at any given time, like some games, but instead simulates everything within a system (along with nearby systems ...but they're independent)

anyways, not to get into ogre at the moment.

It would be good to have volatile systems which we portray as being inside a nebula and give them properties that would be dangerous to travel in.
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 »

For dangerous systems, I've never been near a pulsar, but they don't inspire a lot of confidence. Close binary stars, or stars with
a gas giant in close proximity, I imagine would put out a lot of flares. We could have young blue stars with "dust" disks (-i.e.,
the whole space around the star is one huge ring of rocks and foggy dust. That would be fun; but it needs code, to have a
continuous roid field.
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 think we can think of how to graphically represent various things like special stars independently from creating their effects.

Mostly these effects would be radiation, heat, EM interference, gravity...possible visible light issues (pulsing, non-existent, blindingly intense)

radiation and heat and em and light are all easy to portray, but gravity doesn't really exist in the game. Part of the reason why it's hard to do gravity is that every effected unit would have to be processed each frame, or it wouldn't work right. But we may be able to realistically fake it in a special system where it's obvious the gravity of 1 object is overpowering everything. In such a system, we would give such a unit (neutron star or black hole) the duty of each physics frame, modifying the vector velocity of each unit as a function of distance squared, and then somehow make sure this unit gets processed each frame :)

This would pull units towards it, and you could do realistic orbits. Radiation would destroy your ship long before you got anywhere near the surface of the star/event horizon
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 »

I've thought about pulsars, and what they would look like at planetary distances is something so weird that
players would think it unrealistic.
You have pulsars with oscillation periods, between light and dark, as small as a minute. Some as small as
a second.
But the diameter of the star can be many times its pulsing period times the speed of light.
And since the nearest part to you is around the middle, and near the periphery it's almost
a star radius farther away, what you'd see is a pattern of concentric circles always expanding
from the center; no matter where you look at it from.
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 »

The way to model those things are "affectors".

Basically, big invisible structures that have an effect on objects inside. They can apply damage, forces (gravity), etc...

So you create the graphical elements however you want, and then create the physical elements (affectors) to get the desired physical effects.

So, around a binary starsystem, you'd have the two stars, two spheres slightly bigger than the stars with strong heat and radiation affectors, perhaps with distance decay, a funnel between them (easily modelled as a series of cylinders) modelling the matter stream (the smaller, denser star sucking up the biggest), with instantly-lethal heat effects, and stuff like that.

Then you have the graphical part... the matter stream can be modelled as a very dense flowing particle cloud, flares can be dynamic particle systems that spout big chunks of hot plasma from time to time, perhaps attached to a corresponding affector, so that the plasma jet does its thing.

Anyway... VS lacks all that, which is an important part of any game. Static scenery.
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've thought about pulsars, and what they would look like at planetary distances is something so weird that
players would think it unrealistic.
You have pulsars with oscillation periods, between light and dark, as small as a minute. Some as small as
a second.
But the diameter of the star can be many times its pulsing period times the speed of light.
And since the nearest part to you is around the middle, and near the periphery it's almost
a star radius farther away, what you'd see is a pattern of concentric circles always expanding
from the center; no matter where you look at it from.
I think you got pulsar's pulsing characteristic wrong. Pulsars are rotating ellipsoid neutron stars that eject a strong relativistic electron jet along their magnetic poles, and surrounded by a fluid electron cloud. The jet turns basically in strong radiation, X-ray or gamma, although a lot more broadband than usually credited according to late papers. Or something like that, I've read.

The oscillating electron jet creates a radiation pattern that moves faster than the speed of light - the oscillation does, along with the perturbations on its magnetic field, although not the electrons themselves. What observers might see has been theorized, and it's not concentric circles since it's not the whole star which is pulsing, the pulsating effect is given by the oscillating radiation jet, which creates the illusion of pulsation when it only periodically points towards the viewer.
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 »

the thing about pulsars is that they're just spinning neutron stars. Not much bigger than a city is wide. How it would look would likely be fairly black hole-like. it's spinning and gravitational field would produce an accretion disk most likely and it's jets would rapidly be spinning like a wobbly top. You wouldn't see much of the jets outside of the plasma glow. The radiation would be immense. The gravity immense. But more importantly, if you ever cross the path of the jets, it would be the last thing you ever did.


You would never survive to get close enough to see much if any of the actual body of the pulsar.
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 »

I've just learned a lot about pulsars. Good links.
I suspect I was talking about something else, though, presumably going by some other name; because
the description I remember reading was not at all the way pulsars are described there. Maybe
"variable stars"? Not sure.
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 »

The accretion disk and the jets are probably the most universally recognized and visually attractive elements.

Plus you can conduct missions in the outer edge of the accretion disk, which would be fun... all that colliding matter and gravitational shear.
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:"variable stars"? Not sure.
There's a lot of types of variable stars

Your description sounds like a pulsating white dwarf
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 »

damage or effects to units can be handled like weapons. it would traverse the system unit list and simply apply a damage to the units as function of their distance from the object (be it squared or otherwise) and in the case of gravity, we could create a special function in ship units (gotta give them their own unit so they're not referred to as what should be a common unit class object). that can receive kinematic input without triggering the damage functions...so we can "push" a ship in a direction invisibly. We would use this function to push a ship towards our gravity well each frame.

That much should be easy to do. So we can handle heat, radiation, gravity with not a whole lot of editing. Then there is the EM interference, which nebula unit already does, so we just steal that and make it a weapon in much the same way as radiation and heat will be.

Now, if you want to do binary star systems ...rapidly orbiting eachother and such.....stuff we can't do with "stars" because they're stationary, we can create a new unit class type called "DStarUnit" standing for dynamic star unit. This unit is more like a planet than a star, so it can orbit and have subunit "moons". So we can make a DStarUnit behave and look like a regular star system, or we can do something like having a binary star system orbiting eachother every 10 minutes. And truly have it orbiting eachother, rather than one orbiting the other. DStarUnits are effected by the special star weapons the same way other units are. Meaning, gravity weapon is used by one DStar ...pushing the other star towards it, then the other DStar does the same thing. To keep from colliding, we have to give them an initial perpendicular velocity that creates a stable system. (should be fun).

Gas exchange and the such will be tricky. We dont have any effects or features that mimic that even closely.


Accretion disks can be mimicked by using the setup we have for rings and modifying it to be much denser looking, and producing it's own light. i dont think you'd haveto worry about flying through one, you'd be dead as the disk would produce insane levels of every harmful radiation you can imagine .
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, I'd rather not hack our way through the feature.

Lets add truly static scenery. It will pay off... artists will make it pay off.

Heck... a star shouldn't be a unit... it should be static scenery.

With static scenery we could have true asteroid fields and belts.

Anyway, about nebulas, the fourth rendering layer I was talking about is pretty much implementable on the current engine. It was merely an idea I had when rewriting the graphics engine around Ogre, but it's applicable in the current engine.

We just need static scenery at the galactic level.
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 »

I dont get your term "static scenery"

Nothing about what we're describing is static. Nor is it stationary. Also, it's not much in the way of scenery when you can directly interact with it. Ie, I'd be able to realistically enter an orbit around a DStarUnit in a newtonian fashion. That's beyond the scope of scenery in my book.

But maybe the term means something other than what it literally looks like it means. In which case i'd say it had a bad name :)


Anyway, i dont consider creating the unit a hack, rather than it's effects being somewhat hack sounding. Though, i dont think you'd find a more efficient means of transporting the forces to units than by pretending that they are weapons or by using kinematics with no damage to mimic gravity.
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 »

I think what he means is the difference between a body that has a "static orbit" (precalculated circle or ellipse), versus
a body whose orbit is continuously simulated based on forces, like centrifugal versus gravity, each physics step.

EDIT:
Gravity code is in the engine already, anyways; it's just disabled, AFAIK.
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 also dont see how making stars a non-unit has anything to do with asteroid fields that behaved more realistically.

The only thing that keeps us from creating realistic asteroid fields is the utter insane amounts physics calculations that would have to be done on each asteroid ..and the sheer numbers of them all along with their other technical requirements. Plus, we dont do gravity currently, which would be required for each unit to enable them to stay as a field. The fact that they're Units doesn't inhibit us. The fact that the common Unit object is not what it should be may be part of the reason why memory is a factor when talking about thousands of instances of units in the game (though that can be fixed by fixing unit).

the thing about asteroid belts is that they only appear as something denser than empty space from pretty far away. A much denser at close range asteroid field would indicate a recent destruction of some planetoid body. In any case, it's the lack of gravity and the bloatedness of the base unit class that keeps us from doing these things, not the stars being units.
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 »

chuck_starchaser wrote:I think what he means is the difference between a body that has a "static orbit" (precalculated circle or ellipse), versus
a body whose orbit is continuously simulated based on forces, like centrifugal versus gravity, each physics step.

EDIT:
Gravity code is in the engine already, anyways; it's just disabled, AFAIK.

i dont know, static scenery still doesn't seem to fit either one of those. We have the first already, and since he is suggesting something other than what we have, it can't be that, and the other is completely not static...


i think gravity code in the game is unstable...in that acts on too much, and the systems aren't balanced and it's completely unuseable in that way. I would have to modify it to be emitted voluntarily and recieving it would be non-voluntary. That way, we dont have to worry about everything we dont care about dealing with gravity, it would work as it does now. But on special things like DStars, we could turn it on.
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 »

The stars being units is an example of pointless oversimulation.

Static scenery means something close to what chuck described. Scenery is obvious: pretty objects. Decoration. It may be gameplay decoration, ie, decoration that affects gameplay. That is the case with sandbags in a shooter game, they're static, but they provide gameplay by providing cover.

Static scenery is, thus, objects that enhance gameplay by just being there. Be it visually, or with simple scripted interaction.

Static thus relates to the simplicity of its interaction. Visual scenery only paints an object on the screen. It does nothing more than that. Not even physical collisions - only a drawing. It may move, but in scripted fashion - no expensive simulation.

That is what a star should be, that's why I put the stars as examples. If you have a lethal radiation field around the star, the visible star is mere visual scenery - you can't reach it to interact with it. You can't dock with it. You can't talk to it. You can't even collide with it. If a star is a unit, it has all that and more. It has AI, it has a collision mesh, it has shields, it has everything. It's a waste of resources.

Stars are few. Wasting thus little resources. Asteroids are many. Asteroids only need a collision mesh. And given that there are thousands of them, they need special consideration. They can't be generic units. They're visual and physical scenery. They're merely visual when seen from a distance, they're physical when seen up close. They don't need shields, energy, weapons, AI, or anything other than a shared physical mesh, and a packed (probably procedural) description of the position of every asteroid in the field. They don't have to be rendered one by one at the distance, impostors are enough. They have to be instanced as physical entities only when you enter their sphere of influence. They're thus NOT units.

Dust fields are visual scenery. They get rendered like asteroids: an impostor cloud in the distance, a debris field (like the flying stars) up close. They don't interact.

Affectors are gameplay scenery. There's force fields, there's heat fields, there's radiation fields. They're not units, though. They don't need to have weapons, they don't need to have AI, they have hardcoded and/or scripted effects on the units entering their area of influence. There's even sound fields (irrealistic but pretty, we had discussed it already chuck, remember?).

So here "static" refers, again, to the lack of simulation. Scripted behavior if any.

Also, applying damage as if it were a weapon IS a hack. There should be an "applyRadiationDamage", "applyHeatDamage", etc functions in code - if only to separate the entry points, and allow for easier maintainability. Suppose I want, later on, to add a HUD warning when you enter a radiation field... what's the best way... tapping into applyRadiationDamage to sense the effects of the radiation field, or querying the affector map every frame to see if I'm inside one?
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 »

I do remember.
Affectors sound cool.
BTW, class Unit ... :roll: ... in unit_generic.cpp, is the three-headed dog of the medusa (Cerberos?). This galaxy-size class
is divided into a gazillion sections. I was thinking of chopping it up into many classes that... --I was going to say Unit would
inherit from, but-- ... that Unit could instantiate as members, or allocate to pointer members...
After doing that, and making it work, hopefully, we could perhaps begin to have various types of "composites", like some
may have AI but not be able to buy and trade commodities, for example.
Perhaps the composites could inherit from an AbstractUnit, and allocate or not allocate the various modules to pointer
members inherited from AbstractUnit.
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:The stars being units is an example of pointless oversimulation.

Static scenery means something close to what chuck described. Scenery is obvious: pretty objects. Decoration. It may be gameplay decoration, ie, decoration that affects gameplay. That is the case with sandbags in a shooter game, they're static, but they provide gameplay by providing cover.

Static scenery is, thus, objects that enhance gameplay by just being there. Be it visually, or with simple scripted interaction.

Static thus relates to the simplicity of its interaction. Visual scenery only paints an object on the screen. It does nothing more than that. Not even physical collisions - only a drawing. It may move, but in scripted fashion - no expensive simulation.
what we were describing was not simply passive though. It is an active interaction with other objects.
That is what a star should be, that's why I put the stars as examples. If you have a lethal radiation field around the star, the visible star is mere visual scenery - you can't reach it to interact with it. You can't dock with it. You can't talk to it. You can't even collide with it. If a star is a unit, it has all that and more. It has AI, it has a collision mesh, it has shields, it has everything. It's a waste of resources.
unit shouldn't have that shit though. Unit should be what is common to every unit in the game. Anything that can be destroyed and has physics should be a unit. Now, should a planet or a star necessarily be a unit then, as they can't be destroyed? 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.

Now, i dont believe stars are merely visual scenery simply because you die before you can reach it. You can fly around a star, you are affected by the forces coming off from it. 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.

The star is interactive, not just the forces imparted from it, because these forces all depend on distance from the star and it makes _MUCH_ more sense for the star to be initiating these forces.
Stars are few. Wasting thus little resources. Asteroids are many. Asteroids only need a collision mesh. And given that there are thousands of them, they need special consideration. They can't be generic units. They're visual and physical scenery. They're merely visual when seen from a distance, they're physical when seen up close. They don't need shields, energy, weapons, AI, or anything other than a shared physical mesh, and a packed (probably procedural) description of the position of every asteroid in the field. They don't have to be rendered one by one at the distance, impostors are enough. They have to be instanced as physical entities only when you enter their sphere of influence. They're thus NOT units.
objects dont cease to take up space in a system just because the player isn't there. Other ships may be in the asteroid field. Two ships may be on either side of an asteroid and fire a missile. it should hit the asteroid if it's in the way. like i said though, unit shouldn't contain all that stuff because a unit describes objects that dont always have those things. But i would make an asteroid a planetoid object, and not a unit at all. You dont have to worry about visual rendering at a distance, openGL takes care of culling what isn't seen on screen. Physical simulation _MUST_ be persistent within a system, regardless of visibility. we can fake things in other systems because we really can't observe in any way what's going on. But within our system, we can't have an asteroid field become non-existent just because the player moved far enough away from it. It may be protecting a ship ...or impeding it. etc etc.

In any case, i would say asteroids would be planetoid objects and operate with gravitons enabled. That's the only means i can see asteroids being anything more than cartoon like representations like we currently have. Either that, or you would have to give them some type of fixed orbit to operate with gravitons off.
Dust fields are visual scenery. They get rendered like asteroids: an impostor cloud in the distance, a debris field (like the flying stars) up close. They don't interact.
I really dont like the idea of physical objects that disappear dependent on player location. It's wrong. Think of each unit in the game as a player with only the visuals dependent on the human player. Everything else has to exist as if it was the human player piloting any given unit.

Affectors are gameplay scenery. There's force fields, there's heat fields, there's radiation fields. They're not units, though. They don't need to have weapons, they don't need to have AI, they have hardcoded and/or scripted effects on the units entering their area of influence. There's even sound fields (irrealistic but pretty, we had discussed it already chuck, remember?).
An affector has to have a source. This intrinsically becomes an object of the parent object. The force field around a ship doesn't get owned by the system. it's owned by the ship. 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.
So here "static" refers, again, to the lack of simulation. Scripted behavior if any.
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. We may even decide that we'd like to see a planet destroyed all death star-esque. Or maybe a star can go nova in a system that is involved in a "race against time" type mission during a future campaign we haven't written yet. etc etc. I would keep static things left to things you have no interaction with.

Also, applying damage as if it were a weapon IS a hack. There should be an "applyRadiationDamage", "applyHeatDamage", etc functions in code - if only to separate the entry points, and allow for easier maintainability. Suppose I want, later on, to add a HUD warning when you enter a radiation field... what's the best way... tapping into applyRadiationDamage to sense the effects of the radiation field, or querying the affector map every frame to see if I'm inside one?
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.

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.

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. 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. 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" ... 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.

The only thing that would have to be handled as a special case is the EM interference, because this affects a specific subsystem without necessarily imparting damage to the unit. This would have to be done via an effector field.
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 »

chuck_starchaser wrote:I do remember.
Affectors sound cool.
BTW, class Unit ... :roll: ... in unit_generic.cpp, is the three-headed dog of the medusa (Cerberos?). This galaxy-size class
is divided into a gazillion sections. I was thinking of chopping it up into many classes that... --I was going to say Unit would
inherit from, but-- ... that Unit could instantiate as members, or allocate to pointer members...
After doing that, and making it work, hopefully, we could perhaps begin to have various types of "composites", like some
may have AI but not be able to buy and trade commodities, for example.
Perhaps the composites could inherit from an AbstractUnit, and allocate or not allocate the various modules to pointer
members inherited from AbstractUnit.
i would say the ultimate object is the graviton object. it's the base of the base. Everything that has physical presence in the game gets it. It may be off, it may be on, doesn't matter.

on top of the graviton sits 3 objects. Unit, planetoid, star. On top of Unit sits bases, ships, missiles.

A ship is different from a base because bases have no physical presence in the 3d universe. (so far). Yet they have a physical presence in the game and can do many things like contain ships, dock, etc, maybe even fire missiles one day.

Missiles are different from ships because missiles have no cockpit, and thus no rooms at all.

Everything else is a type of ship, including starbases, mining bases visible on asteroids and the like.

What differentiates a "starbase" from a regular ship is just a significant unit flag we can use so that they are detected in python as being special, like planet side bases and capital ships.

What differentiates a planetoid from a star is that planetoids would one day have things like an immersive atmosphere and environment to land and fly in. So it's best to differentiate them now. Plus, they have multiple textures and are technically effected by ship weapons and can readily be destroyed if small enough or the weapons powerful enough.
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 »

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.
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?
safemode wrote:unit shouldn't have that shit though. Unit should be what is common to every unit in the game. Anything that can be destroyed and has physics should be a unit.
That makes sense. But it's not how things are right now. And, besids...
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.

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.

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.
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)
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 vecinity 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.

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.

It's completely different with the visual representation of the cause of those effects. There I need a different spatial culling model, one that will allow me to query which objects are within view.

So I really want them as different objects, so that I can organize them differently.
safemode wrote:Other ships may be in the asteroid field. Two ships may be on either side of an asteroid and fire a missile. it should hit the asteroid if it's in the way.
Indeed that's a complexity the implementation will have to deal with. Not discarding anything is a gross, but effective way to deal with it.
But that results in the limitations current VS has. I was hoping to propose something that goes beyond those limitations. I was hoping to propose something that would allow millions of small objects - say for a planetary ring. I was hoping to propose a framework that lets us approximate any effect we want to the degree we want and can afford.
safemode wrote:You dont have to worry about visual rendering at a distance, openGL takes care of culling what isn't seen on screen.
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.
safemode wrote:Physical simulation _MUST_ be persistent within a system, regardless of visibility.
That's a fallacy. It needs not.
You may want persistence if you blow up a moon, a base. But you certainly don't need persistence if you blow up a meter-sized rock in a planetary ring. Less even so if all you do is push it aside. You want to see the effect when you're doing it, but once you leave the area, you forgot about it.

The idea of static scenery is that you have no such persistent state, because the state is always what the .system file says. So asteroid fields aren't so static, they have a state, but it's volatile state... it's ok to discard it when you leave.
safemode wrote:But within our system, we can't have an asteroid field become non-existent just because the player moved far enough away from it. It may be protecting a ship ...or impeding it. etc etc.
There are other ways to account for asteroid fields at the distance. That's why they must be something special - not units. There's stochastic simulation, for instance.
I fire a missile through an asteroid field - so I roll the dice for every km the missile travels inside the system, and perhaps it rolls 1 and the missile explodes. It hit a rock.
If you're on the other side and the scene takes only 10 pixels on your screen, the purpose is served.
I'm not saying we implement all that - but I'm saying we begin implementing the required framework. Which is allowing for non-unit types.
safemode wrote:I really dont like the idea of physical objects that disappear dependent on player location. It's wrong.
Shake that feeling off your head. It's not wrong to approximate when the problem is too complex for a game to solve.
safemode wrote:
Affectors are gameplay scenery. There's force fields, there's heat fields, there's radiation fields. They're not units, though. They don't need to have weapons, they don't need to have AI, they have hardcoded and/or scripted effects on the units entering their area of influence. There's even sound fields (irrealistic but pretty, we had discussed it already chuck, remember?).
An affector has to have a source. This intrinsically becomes an object of the parent object.
Only when it helps you. When it doesn't, don't do it that way.
In the case of stellar phenomena, I don't believe having the affector attached to a source really helps you in any way. In fact, it hurts you - because it forces you to consider units as possible containers of affectors.
safemode wrote:The force field around a ship doesn't get owned by the system. it's owned by the ship.
That's practical. The ship has an AI that controls the force field in many many ways, so modelling it like that is in fact practical.
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.
safemode wrote:
So here "static" refers, again, to the lack of simulation. Scripted behavior if any.
static means unchanging. That would imply the scripted behavior is immutable.
It is indeed.
safemode wrote:We may even decide that we'd like to see a planet destroyed all death star-esque. Or maybe a star can go nova in a system that is involved in a "race against time" type mission during a future campaign we haven't written yet. etc etc. I would keep static things left to things you have no interaction with.
Then the behavior is static up to that point in time. At which point the structure of the system is modified by a higher level script.
Nothing is static if you consider an infinite lifespan and every potential campaign and story. Consider a short timespan. The most common scenario.
Exceptions can be implemented by modifying the list of static things from higher level code.
safemode wrote: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?
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".
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.
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.
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.
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.
Oíd mortales, el grito sagrado...
Call me "Menes, lord of Cats"
Wing Commander Universe
Post Reply