0.6 plans

Development directions, tasks, and features being actively implemented or pursued by the development team.
Post Reply
Deus Siddis
Elite
Elite
Posts: 1363
Joined: Sat Aug 04, 2007 3:42 pm

Re: 0.6 plans

Post by Deus Siddis »

safemode wrote:the point being that I'm seriously thinking of making ogre an immediate priority of mine...
:!:
the specifics likely meaning we would maintain our own copy of ogre and modify it to handle the extra precision we need. I haven't got into it yet but it looks like that would be the smartest direction to take
You should really consider if there is a way to contribute back to the OGRE project whatever double precision solution you select. Then they might help maintain it and a thousand other large environment projects could benefit.
also, I'm looking into the latest bullet physics library. it supports open cl colliding. as well as soft body colliding among other things.
I imagine it would eliminate the ships-getting-stuck-in-stations issue as well.
klauss
Elite
Elite
Posts: 7243
Joined: Mon Apr 18, 2005 2:40 pm
Location: LS87, Buenos Aires, República Argentina

Re: 0.6 plans

Post by klauss »

Ogre already supports double precision. The problem is, such support is inconsequential with hardware T&L (that is, our target GPUs), because the hardware itself rarely supports double precision (and when it does, it's only for CUDA, not geometry).

A simple transform to viewer-centric coordinates fixes all, so it's not difficult feeding Ogre with float-safe data.

Still, viewing distances vary wildly in VS scenes, and this brings the GPU's z-buffer to its knees. If you expand range to encompass that distant planet, you loose valuable precision at the near scale (most pathologically the cockpit).

For this, VS uses a layered approach, with drawing happening on at least 3 layers and stages: far, near and cockpit. Each stage clears and re-calibrates the Z-buffer. It's not optimal for the GPU, but it's far better than any alternative. And far uses an infinite projection matrix, that provides the exact environment needed to render planets (but isn't good enough for ships and stations).

Doing that on Ogre is a bit more involved, but possible with render sequence listeners and careful manipulation of entity render sequences.

All that had been sketched on the ogre branch. It's probably very outdated now, but the techniques remain. So Ogre needs no adaptation beyond its already vast extensibility.
Oíd mortales, el grito sagrado...
Call me "Menes, lord of Cats"
Wing Commander Universe
Deus Siddis
Elite
Elite
Posts: 1363
Joined: Sat Aug 04, 2007 3:42 pm

Re: 0.6 plans

Post by Deus Siddis »

klauss wrote: For this, VS uses a layered approach, with drawing happening on at least 3 layers and stages: far, near and cockpit. Each stage clears and re-calibrates the Z-buffer. It's not optimal for the GPU, but it's far better than any alternative.
What about that hack-y-sounding solution where once an object gets a certain distance away from the camera, you start scaling the object down while only allowing it to get further away at a reduced rate? So what looks like distant planets in game would actually be not-so-distant miniaturized planets.
Doing that on Ogre is a bit more involved, but possible with render sequence listeners and careful manipulation of entity render sequences.
All that had been sketched on the ogre branch. It's probably very outdated now, but the techniques remain. So Ogre needs no adaptation beyond its already vast extensibility.
So that wouldn't be worth making into its own library that ships with OGRE? Or would it be too specifically calibrated to the needs of VS, to be useful for other large world games in general?
klauss
Elite
Elite
Posts: 7243
Joined: Mon Apr 18, 2005 2:40 pm
Location: LS87, Buenos Aires, República Argentina

Re: 0.6 plans

Post by klauss »

Deus Siddis wrote:
klauss wrote: For this, VS uses a layered approach, with drawing happening on at least 3 layers and stages: far, near and cockpit. Each stage clears and re-calibrates the Z-buffer. It's not optimal for the GPU, but it's far better than any alternative.
What about that hack-y-sounding solution where once an object gets a certain distance away from the camera, you start scaling the object down while only allowing it to get further away at a reduced rate? So what looks like distant planets in game would actually be not-so-distant miniaturized planets.
I tried something similar, which was to auto-optimize the z-buffer for the relevant units (pretty much the same to what you propose in terms of complexity), and it was very difficult to actually decide where to put the units.

Not to mention your way would hurt lighting.
Deus Siddis wrote:
Doing that on Ogre is a bit more involved, but possible with render sequence listeners and careful manipulation of entity render sequences.
All that had been sketched on the ogre branch. It's probably very outdated now, but the techniques remain. So Ogre needs no adaptation beyond its already vast extensibility.
So that wouldn't be worth making into its own library that ships with OGRE? Or would it be too specifically calibrated to the needs of VS, to be useful for other large world games in general?
I think yes, it would be too VS-specific.
Oíd mortales, el grito sagrado...
Call me "Menes, lord of Cats"
Wing Commander Universe
log0

Re: 0.6 plans

Post by log0 »

There is a very simple alternative, which I've run into when messing with ogre planet. Pioneer is using a variant of it. It is a shader based solution called logarithmic transform: https://github.com/pioneerspacesim/pion ... /logz.glsl
safemode
Developer
Developer
Posts: 2150
Joined: Mon Apr 23, 2007 1:17 am
Location: Pennsylvania
Contact:

Re: 0.6 plans

Post by safemode »

planets ought to just get rendered normal until they hit the z buffer limit then they become a special case that shrinks the planet at the edge of the zbuffer until it is too small. and vice versa on approach. I don't see how that could cause any inconsistencies. ships and everything else should be culled before that limit due to their tiny size so nothing will be interacting with our shrunk planet from player perspective.

in any case, this work isn't going down yet and I don't know if I'll decide to approach it much differently from previous attempts. I think everyone is on board with making a release before all that, and 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: 0.6 plans

Post by klauss »

safemode wrote:planets ought to just get rendered normal until they hit the z buffer limit then they become a special case that shrinks the planet at the edge of the zbuffer until it is too small. and vice versa on approach. I don't see how that could cause any inconsistencies. ships and everything else should be culled before that limit due to their tiny size so nothing will be interacting with our shrunk planet from player perspective.
1 word.

Lights.

2 words

Ring systems

2 more words

Asteroid fields

In essence, there are many multiple-mesh structures, and even the simplest single-mesh structure interacts with lights and occluders, so it's not as simple as fumbling position vectors and scaling.

I'd rather consider logz. How is logz different from infinite projections?
Oíd mortales, el grito sagrado...
Call me "Menes, lord of Cats"
Wing Commander Universe
log0

Re: 0.6 plans

Post by log0 »

Infinite projection matrix allows you to use very large z values. But you will still waste most of z buffer on values close to near plane. This is where the log trick is used. It shifts the distribution, so that you will gain more precision for far values and lose some for the near ones.
klauss
Elite
Elite
Posts: 7243
Joined: Mon Apr 18, 2005 2:40 pm
Location: LS87, Buenos Aires, República Argentina

Re: 0.6 plans

Post by klauss »

We could try it. But that already requires a level of hardware support that might be quite restrictive. Most low-end onboard GPUs didn't support writing to the z-buffer on the fragment shader last time I checked. I ought to check again.

Alternatively, it could be an optimization for those architectures that do support it.
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: 0.6 plans

Post by safemode »

any card predating open gl3 should not be a concern of ours when programming. 5 years is more than a generous amount of time. anything based off 3 should support such shader features in hardware or software.


edit. unless it is not in the standard. by default shaders go before depth test but you can tell it to run depth test early.
Ed Sweetman endorses this message.
log0

Re: 0.6 plans

Post by log0 »

klauss wrote:We could try it. But that already requires a level of hardware support that might be quite restrictive. Most low-end onboard GPUs didn't support writing to the z-buffer on the fragment shader last time I checked. I ought to check again.

Alternatively, it could be an optimization for those architectures that do support it.
There is a vertex shader only variant too (I've used it for planet code). It has some minor issues "artifacts occurring with thin or large triangles when close to the camera, when perspectively interpolated depth values diverge too much from the logarithmic values". I haven't noticed them with planets though, so they might be acceptable, need testing.
klauss
Elite
Elite
Posts: 7243
Joined: Mon Apr 18, 2005 2:40 pm
Location: LS87, Buenos Aires, República Argentina

Re: 0.6 plans

Post by klauss »

safemode wrote:any card predating open gl3 should not be a concern of ours when programming. 5 years is more than a generous amount of time. anything based off 3 should support such shader features in hardware or software.


edit. unless it is not in the standard. by default shaders go before depth test but you can tell it to run depth test early.
There was a "GLSL profile" or whatever it's called, a GLSL version, which didn't support this. And most workable MESA drivers for intel didn't support it, last time I checked. But I checked with say MESA 7, so it's a long way back. I ought to re-check.

In any case, depth fumbling does push the depth test to after the fragment shader, even on high end, which is a performance hit, because it disables early z-culling and hierarchical z-buffer optimizations. In essence, if we do this, our two-pass techniques that first write the z-buffer and the write the color buffer, to avoid running the expensive fragment shaders on occluded pixels, wouldn't work.
Oíd mortales, el grito sagrado...
Call me "Menes, lord of Cats"
Wing Commander Universe
Deus Siddis
Elite
Elite
Posts: 1363
Joined: Sat Aug 04, 2007 3:42 pm

Re: 0.6 plans

Post by Deus Siddis »

klauss wrote: I propose something better. Put in one CSV the columns you think are related stats that have to be edited as a group and can be edited as a group on a spreadsheet, and I'll get you split CSV support.
I have been giving this some thought and I think what we need is to break up units.csv based on rows, as well as columns. There are so many things in units which only need a handful of columns. Like armor for example, should an armor upgrade really have rows for thruster performance, trade items or weapons? Should planets have armor or cargo capacity columns?

So there would be a separate CSV file for each type of upgrade and then one for planets and asteroids and then one for ships and stations. And each of these CSVs would have only the columns that are relevant to its contents.
klauss
Elite
Elite
Posts: 7243
Joined: Mon Apr 18, 2005 2:40 pm
Location: LS87, Buenos Aires, República Argentina

Re: 0.6 plans

Post by klauss »

You'll have that support too, my plan is to simply chain-load the CSVs, combining rows and columns.
Oíd mortales, el grito sagrado...
Call me "Menes, lord of Cats"
Wing Commander Universe
Deus Siddis
Elite
Elite
Posts: 1363
Joined: Sat Aug 04, 2007 3:42 pm

Re: 0.6 plans

Post by Deus Siddis »

So do you want me to break up units.csv into the desired pieces and post them?

And should this feature go on the tracker?
klauss
Elite
Elite
Posts: 7243
Joined: Mon Apr 18, 2005 2:40 pm
Location: LS87, Buenos Aires, República Argentina

Re: 0.6 plans

Post by klauss »

Post, and track if you can. I'm busy lately, and trackers leave an email tread I can follow when I have the time.

I'll try to pass this for 0.5.2.
Oíd mortales, el grito sagrado...
Call me "Menes, lord of Cats"
Wing Commander Universe
Deus Siddis
Elite
Elite
Posts: 1363
Joined: Sat Aug 04, 2007 3:42 pm

Re: 0.6 plans

Post by Deus Siddis »

So I am separating units.csv into the sections and in the process I have turned up many questions in need of answers--

1) Should I make the ships fully upgrade based on the data end as part of this process? Is there much sense in, for example, the CSV file for ships/stations having columns for armor or reactors if these will be exclusively handled by upgrades in the near future?

2) How does the tractorability column work? What does this string "pPil" that shows up in it mean?

3) Does the object_type column do anything in the engine?

4) Do turrets really need armor? Without armor, can their mounted weapons be destroyed on the first shot, even if they have immense hull strength?

5) What effect does collide_subunits have on turrets if it is True?

6) Which column defines Rlaan armor as regenerating?

And finally what do all of the following columns mean in the first place:

wormhole
bsp_mesh
rapid_mesh
hud_functionality
max_hud_functionality
sound
explosion
net_comm
num_chunks
chunk_0


?
klauss
Elite
Elite
Posts: 7243
Joined: Mon Apr 18, 2005 2:40 pm
Location: LS87, Buenos Aires, República Argentina

Re: 0.6 plans

Post by klauss »

Deus Siddis wrote:So I am separating units.csv into the sections and in the process I have turned up many questions in need of answers--

1) Should I make the ships fully upgrade based on the data end as part of this process? Is there much sense in, for example, the CSV file for ships/stations having columns for armor or reactors if these will be exclusively handled by upgrades in the near future?
That would be a bigger task. Making them fully upgrade-based should be left for later.
Deus Siddis wrote:2) How does the tractorability column work? What does this string "pPil" that shows up in it mean?
It defines who can tractor who. I don't remember the exact semantics, but checking the source, having a "p" there (upper or lower) allows pushing of said unit, where having an "i" (upper or lower) allows capturing (tractoring *i*n).

I remember there were some caveats (ie: there are some rules about capturing that go beyond the flags), but I don't remember the details, and in essence that's that.
Deus Siddis wrote:3) Does the object_type column do anything in the engine?
I have no idea. Lets assume it does.
Deus Siddis wrote:4) Do turrets really need armor? Without armor, can their mounted weapons be destroyed on the first shot, even if they have immense hull strength?
Hull hits can result in weapon damage, so yes, I'd imagine they'd have armor. More armor than hull, in fact, if battleships are any indication.
Deus Siddis wrote:5) What effect does collide_subunits have on turrets if it is True?
I think it's primarily geared towards asteroid fields (where you want subunit collisions). In any case, that's part of the "primary" data set (ie, all units need it, it's like a global config), along with tractorability, unit type, and who knows what else.
Deus Siddis wrote:6) Which column defines Rlaan armor as regenerating?
I don't think there's such a thing. Is there?
Deus Siddis wrote:And finally what do all of the following columns mean in the first place:

wormhole
bsp_mesh
rapid_mesh
hud_functionality
max_hud_functionality
sound
explosion
net_comm
num_chunks
chunk_0
Lets see... not sure what wormhole, num_chunks, chunk_0 or net_comm are. bsp and rapid mesh are collision meshes, if there are any. Not sure what the difference among those is. It's geometry. Functionality ones are damage values, I don't think they should be on the CSV, but I'm not sure they're removable either. They should be (all ones should be the default), but I cannot confirm this right now.

sound, I think, is the engine sound file. I'd like to replace it with a structure with different sounds for different events and stuff like that, but it's not the time for that yet.

explosion should be self-explanatory. It's the explosion animation. I think there's a per-faction default.
Oíd mortales, el grito sagrado...
Call me "Menes, lord of Cats"
Wing Commander Universe
Deus Siddis
Elite
Elite
Posts: 1363
Joined: Sat Aug 04, 2007 3:42 pm

Re: 0.6 plans

Post by Deus Siddis »

Do turrets and missiles really need radar, reactors, capacitors, upgrade space and most everything else a complete ship would have?
klauss wrote:
Deus Siddis wrote:6) Which column defines Rlaan armor as regenerating?
I don't think there's such a thing. Is there?
I thought so but perhaps I was mistaken. I remember there was something "regenerative" about their craft.
Lets see... not sure what wormhole, num_chunks, chunk_0 or net_comm are.
I wonder how many of these columns are dead code...
bsp and rapid mesh are collision meshes, if there are any. Not sure what the difference among those is.
Turns out BSP_Mesh is exactly what it sounds like. It is used only by nebulae, presumably for internal collision detection so it can screw with your radar when you are inside its bounds. Rapid mesh is used by no units however. Perhaps it is the collision mesh but then it is surprising that not one of these is in use, with high density graphics meshes used by all units instead.
klauss
Elite
Elite
Posts: 7243
Joined: Mon Apr 18, 2005 2:40 pm
Location: LS87, Buenos Aires, República Argentina

Re: 0.6 plans

Post by klauss »

Deus Siddis wrote:Do turrets and missiles really need radar, reactors, capacitors, upgrade space and most everything else a complete ship would have?
Yes. They can't share it with their parent unit. Sub-units are full units.
Deus Siddis wrote:Turns out BSP_Mesh is exactly what it sounds like. It is used only by nebulae, presumably for internal collision detection so it can screw with your radar when you are inside its bounds. Rapid mesh is used by no units however. Perhaps it is the collision mesh but then it is surprising that not one of these is in use, with high density graphics meshes used by all units instead.
If there isn't one, the engine will derive one from the mesh's lower LOD level. Opcode is quick enough, so you never notice that it's being generated at runtime. But a specialized mesh is really useful, because LODs made for graphics purposes might not represent the geometrical shape very well for collision purposes.

In any case, the engine barely uses it ATM, since the only use for such mesh is to handle ship-to-ship collisions. Bolts or beams don't query the collision mesh yet. Safemode had plans to fix that IIRC.
Oíd mortales, el grito sagrado...
Call me "Menes, lord of Cats"
Wing Commander Universe
Deus Siddis
Elite
Elite
Posts: 1363
Joined: Sat Aug 04, 2007 3:42 pm

Re: 0.6 plans

Post by Deus Siddis »

klauss wrote: Yes. They can't share it with their parent unit. Sub-units are full units.
Seems excessive. The only things turrets need to do are turn and shoot.

So I take it if turrets and missiles are missing radar data or upgrades, then they won't be able to track targets?
Bolts or beams don't query the collision mesh yet. Safemode had plans to fix that IIRC.
I am increasingly looking forward to his physics enhancements.

Also, I will need to slow down ships' linear mobility more for this change. I have seen time and again what a tangible difference moving to a realistic hit detection model makes on games. It allows marksmanship to be equally challenging at more realistic and visually appealing speeds.
klauss
Elite
Elite
Posts: 7243
Joined: Mon Apr 18, 2005 2:40 pm
Location: LS87, Buenos Aires, República Argentina

Re: 0.6 plans

Post by klauss »

Deus Siddis wrote:
klauss wrote: Yes. They can't share it with their parent unit. Sub-units are full units.
Seems excessive. The only things turrets need to do are turn and shoot.

Turrets. But subunits aren't turrets. Subunits are a broader concept.
Deus Siddis wrote:So I take it if turrets and missiles are missing radar data or upgrades, then they won't be able to track targets?
Exactly.
Deus Siddis wrote:
Bolts or beams don't query the collision mesh yet. Safemode had plans to fix that IIRC.
I am increasingly looking forward to his physics enhancements.

Also, I will need to slow down ships' linear mobility more for this change. I have seen time and again what a tangible difference moving to a realistic hit detection model makes on games. It allows marksmanship to be equally challenging at more realistic and visually appealing speeds.
Yes, I'm afraid current speeds will make the game unplayable if precise collision detection is implemented, at least without auto-tracking. That's realistic. But not fun.

Btw... are you going to include your speed rebalance on the split CSVs? I won't bother merging the last patch into trunk if you will, it'll save me some work.
Oíd mortales, el grito sagrado...
Call me "Menes, lord of Cats"
Wing Commander Universe
Deus Siddis
Elite
Elite
Posts: 1363
Joined: Sat Aug 04, 2007 3:42 pm

Re: 0.6 plans

Post by Deus Siddis »

klauss wrote: Turrets. But subunits aren't turrets. Subunits are a broader concept.
Perhaps too broad. I cannot think of any situation where, for examples, sharing reactor power or radar information between unit and subunit does not make sense.
Yes, I'm afraid current speeds will make the game unplayable if precise collision detection is implemented, at least without auto-tracking. That's realistic. But not fun.
I think I'll keep linear speed governors the same but decrease linear accelerations so that 3-5gs is the new maximum.

Things should be slow enough that auto-trackers are never necessary.
Btw... are you going to include your speed rebalance on the split CSVs? I won't bother merging the last patch into trunk if you will, it'll save me some work.
Yes, I am working off the speed rebalance data for the split, so don't merge anything yet.

BTW, can the list of CSV files be in a plain text format instead of compiled into the engine? I think it would be good to be able to split, merge and rename the unit data CSVs without recompiling (since the engine treats them all the same under the hood anyway).
klauss
Elite
Elite
Posts: 7243
Joined: Mon Apr 18, 2005 2:40 pm
Location: LS87, Buenos Aires, República Argentina

Re: 0.6 plans

Post by klauss »

Deus Siddis wrote:
klauss wrote: Turrets. But subunits aren't turrets. Subunits are a broader concept.
Perhaps too broad. I cannot think of any situation where, for examples, sharing reactor power or radar information between unit and subunit does not make sense.
Asteroid fields. Mine fields. To name two.
Deus Siddis wrote:BTW, can the list of CSV files be in a plain text format instead of compiled into the engine? I think it would be good to be able to split, merge and rename the unit data CSVs without recompiling (since the engine treats them all the same under the hood anyway).
The way I've planned it, it will be on the config.
Oíd mortales, el grito sagrado...
Call me "Menes, lord of Cats"
Wing Commander Universe
Deus Siddis
Elite
Elite
Posts: 1363
Joined: Sat Aug 04, 2007 3:42 pm

Re: 0.6 plans

Post by Deus Siddis »

What does the column Heat_Sink_Rating do, if anything? Does the engine really simulate waste heat or have the ability to or is this dead code?

And why don't ships and stations with turrets have Collide_Subunits as True? Won't the turrets not be hit detected this way?
klauss wrote: Asteroid fields. Mine fields. To name two.
Seems like those objects should not be attached to each other in any way. They should be separate units altogether.
The way I've planned it, it will be on the config.
Very good.
Post Reply