Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Topic started by: FekLeyrTarg on February 28, 2019, 05:19:59 am
-
Hello people,
it's time that I once again bring up an idea for a feature.
Over the course of the SCP's history, there have been a few attempts in writing missions in planetary atmospheres or even over planetary surfaces.
For the former, skyboxes were usually used like in WCSaga. For the latter, a huge textured planar-ish mesh was usually used with quite some impressive results, like in Blue Planet Act III.
While working on XWVM, we figured out that most games featuring planetary surfaces (IE aircraft simulators) use some sort of procedure to create these. X-Wing also creates the Death Star's surface that way. Same with Wing Commander III and IV as well as Elite II (Frontier) and Elite III (First Encounters).
Which brings me to the point:
What do you think about having procedural planetary surfaces as part of Freespace Open? Is something like this even feasible for the SCP?
-
It may be possible to do with scripting. The basic idea there would be to have a set of terrain tiles that is spawned as the player moves through the mission space.
-
Would it need pre-built meshes to choose from or could the procedure generate the meshes itself? In X-Wing for instance, there's no mesh of the surface itself. The procedure generates some sort of infinite planes for the surface and the trench, then places the pre-built buildings and turrets on top of it.
-
I think the biggest problem is the AI having no damn idea what to do if it gets close.
-
I think the biggest problem is the AI having no damn idea what to do if it gets close.
Sure, but that effects all ground-missions, what hasn't stopped FREDers from making good ones.
Overall this sounds like a job for ship-create SEXP, unless I misunderstand the whole concept.
-
As mentioned you could do it more effectively with scripting. Ie moving the ground tiles to where the player is (along with having a matching skybox model). I think moving the tiles would be more efficient then creating new ones everywhere.
-
Apart from the AI issues, this is definitely doable with a script at the moment but only with a limited tile set.
If you start to generate the geometry on the fly (e.g. on the GPU via tesselation) then you would need additional, specialized shaders for rendering this geometry and it would also cause issues with collision detection since the engine has no idea what kind of transformations the GPU will do.
-
As mentioned you could do it more effectively with scripting. Ie moving the ground tiles to where the player is (along with having a matching skybox model). I think moving the tiles would be more efficient then creating new ones everywhere.
Could probably done with SEXPs too.
-
That is very true. In my experience though something like this would be much easier to script, though if the person who wanted to make liked sexps better then it is definitively possible that way, too. :)
-
Who doesn't like a good sexp.
-
Wasn't there some "planet" code buried in the game? IIRC calling something "planet" would damage ships flying too close for example.
-
Wasn't there some "planet" code buried in the game? IIRC calling something "planet" would damage ships flying too close for example.
Yep. Just a few days ago I learned that the player ship self-destructs if something named Planet warps in.
-
Wasn't there some "planet" code buried in the game? IIRC calling something "planet" would damage ships flying too close for example.
Found the file which is said to have a "planet," other than briefing icons. It is collideshipship.cpp.
#define PLANET_DAMAGE_SCALE 4.0f
#define PLANET_DAMAGE_RANGE 3 // If within this factor of radius, apply damage.
fix Last_planet_damage_time = 0;
EDIT: I've forgot to add the code in the fred.rc file. This code appears to have something to do with planets.
ID_VIEW_FIGHTERS "Show/Hide Fighter objects"
ID_VIEW_CAPITALSHIPS "Show/Hide Capital Ship objects"
ID_VIEW_PLANETS "Show/Hide Planet objects"
-
Wasn't there some "planet" code buried in the game? IIRC calling something "planet" would damage ships flying too close for example.
Found the file which is said to have a "planet," other than briefing icons. It is collideshipship.cpp.
#define PLANET_DAMAGE_SCALE 4.0f
#define PLANET_DAMAGE_RANGE 3 // If within this factor of radius, apply damage.
fix Last_planet_damage_time = 0;
I... hoped there was a little more than that. That said, if there was the SCP would have used it already...
-
Given the scale of FS with fighters travelling around with a few hundred m/s at best, having 3D planets thousands of km wide doesn't make that much sense.
-
Wasn't there some "planet" code buried in the game? IIRC calling something "planet" would damage ships flying too close for example.
Found the file which is said to have a "planet," other than briefing icons. It is collideshipship.cpp.
#define PLANET_DAMAGE_SCALE 4.0f
#define PLANET_DAMAGE_RANGE 3 // If within this factor of radius, apply damage.
fix Last_planet_damage_time = 0;
I... hoped there was a little more than that. That said, if there was the SCP would have used it already...
Yet to have the functionality. Would it be better if the planet objects be divided as dwarf planets and proper planets, as classified by the IAU back in 2006? For example, Pluto has a diameter of 2,377 km, while Ceres has a diameter of 946 km.
The only limitation is the mission bounds of 700 km. As I found out, removing the hard-coded mission bounds would increase the burden of the renderer, as The E pointed out. But I have yet to test his claims.
-
How hard would it be to externalize this set of functions?
I have a couple ideas on how this could be turned into a weapon...
-
Here's an important tip for SCP topics. Ignore anything Bryan See says, he doesn't know what he is talking about.
Yes, there is a mostly dummied out "feature" that creates an exclusion zone around an object named "planet", but that's as far as that thing ever went.
The mission space limitations, unlike what Bryan said, don't have anything to do with the renderer; the bigger issue is that we are unable to guarantee that physics still work that far out.
Plus, given the speeds FSO is built around, you'll never want to have a mission that would use that much space anyway.
-
Plus, given the speeds FSO is built around, you'll never want to have a mission that would use that much space anyway.
Not entirely true. While I don't think that there're things several thousand km across in a mission (though I'd like to see that :drevil: ), building missions with multiple stages is easier if you can have the next stage just 100 km away especially if the setting is quite big.
-
The mission space limitations, unlike what Bryan said, don't have anything to do with the renderer; the bigger issue is that we are unable to guarantee that physics still work that far out.
Perhaps this could make use of a physics engine, one that works with space combat simulators.
-
Space combat simulators like FS2?
-
Space combat simulators like FS2?
Yes. And Star Citizen and Elite Dangerous to name a few.
-
Space combat simulators like FS2?
Yes. And Star Citizen and Elite Dangerous to name a few.
The relevance of this post to this thread is = 0.
-
Not to derail, but /me grabs popcorn.
Dying nephilim looks like he has done the most with planetary surfaces in-game, would he have any insight?
What about a fractal bumpmap / vertice matrix? I'm only going by limited experience in after effects generate height effects here.
-
20 years ago I would have said this could have been a good use case for... Voxels. 20 years later I know it's a crazy idea but I still secretly hope for someone crazy enough to tinker with it.
-
What about a fractal bumpmap / vertice matrix? I'm only going by limited experience in after effects generate height effects here.
The problem is that we currently do not have a way to get geometry into the game that doesn't involve loading POF files. It's not impossible to add, of course, just complicated (as any alteration to the engine that changes one of its core concepts is).
20 years ago I would have said this could have been a good use case for... Voxels. 20 years later I know it's a crazy idea but I still secretly hope for someone crazy enough to tinker with it.
Voxels are kinda dead as a technology for gaming, as GPUs are optimized for completely different workloads these days.
-
I know, just shooting in the dark. Could this be useful? https://developer.nvidia.com/gpugems/GPUGems3/gpugems3_ch01.html
-
No, not really. The problem isn't the specific techniques used to generate terrain, that's an easy thing to research and relatively straightforward to implement. The problem is integrating this tech into the engine so that it works as expected (i.e. with the terrain having collision detection and so on), and that's something that you won't find in any of the generally available textbooks (unless there's a "The Developer's Guide to what Volition was doing back when they originally wrote this thing" book out there that I missed).
-
My apologies, it's been too long since I coded anything. You guys are perhaps the most competent open source game community around (along with the Zero-k team) and if it was easy you would have solved it already.
From a non-coding point of view, what is your experience with very large objects in the engine?
I know the Inferno team did at least experiment with ships in the tens of kilometers range, but what about mission area-wide surfaces?
With a reasonably low poly-count and a reasonably high distance to hide that, it could be possible to tweak the primitive proximity damage "planet" parameters to keep the player away and a sky-box to emulate the idea that one is fighting in the upper parts of the atmosphere.
Gravitational pull might be trickier to emulate but I'm sure some approximation could be hacked in.
Anything closer to the ground would be a very different ballpark but then FSO is not meant for that anyway.
-
Look at the videos in this thread (https://www.hard-light.net/forums/index.php?topic=87880.360) for some examples of huge terrain models.
-
Experiences of someone who's been frequently playing with huge things.
-When you're putting too many objects more than 100km from mission center or if your ship is more than 100km from mission center the skybox starts to shake.
-Models larger than 100km have rendering issues (according to The_E it's a physics problem). Textures start to flicker. INFR1 for example had a real-sized 3D model of Earth for "Nemesis", which worked fine in Retail but looks broken in FSO.
-Gravity can be scripted, there's atleast 1 working script.
-
Experiences of someone who's been frequently playing with huge things.
-When you're putting too many objects more than 100km from mission center or if your ship is more than 100km from mission center the skybox starts to shake.
-Models larger than 100km have rendering issues (according to The_E it's a physics problem). Textures start to flicker. INFR1 for example had a real-sized 3D model of Earth for "Nemesis", which worked fine in Retail but looks broken in FSO.
-Gravity can be scripted, there's atleast 1 working script.
These two issues may need to be addressed. Particularly the number of stars and the FS1-style nebulae. And the draw distance. Geometry instancing, occlusion culling and image-based rendering, where 2D elements are manipulated to appear in a 3D world.
For image-based rendering, in the context of a 3D game, it delivers a significant performance boost by replacing 3D geometry that is far enough away for the transition to be imperceptible with a 2D image. Implementation of the technology in this role can be found applied to Rome: Total War's soldiers, Far Cry's forests, and various objects in Guild Wars' environments, such as buildings and flora. FSO can theoretically implement this to faraway ships and objects.
FWIW, many modern game engines as of now can render large distances. FSO needs to address these issues based on experiences of someone playing with huge things as Nightmare provided.
-
I have no clue what you're trying to say to me, I'm just wondering that olde Retail exes were able to do something FSO can't (rendering the 12000km Earth model without trouble).
-
*words*
Bryan, you're doing that thing again where you are saying words with no understanding of what they mean. Stop it.
And by "stop it", I mean "do not post in this thread again". Noone has the time or patience to keep to explaining to other people why and how you're wrong (since explaining it to you doesn't seem to work).
-
I have no clue what you're trying to say to me, I'm just wondering that olde Retail exes were able to do something FSO can't (rendering the 12000km Earth model without trouble).
There are many variables at play here. FS2 ran on very different graphics APIs, on very different hardware; the basic issues that cause rendering errors in FSO (that is, floating point inaccuracies being multiplied over and over by the renderer doing math on very large numbers) were present back then as well, even if it was not noticeable.
-
Aww, that sounds like the kind of things that can't be fixed. :(
(in particular if I'm the only one with use for that) :lol:
-
I have no clue what you're trying to say to me, I'm just wondering that olde Retail exes were able to do something FSO can't (rendering the 12000km Earth model without trouble).
There are many variables at play here. FS2 ran on very different graphics APIs, on very different hardware; the basic issues that cause rendering errors in FSO (that is, floating point inaccuracies being multiplied over and over by the renderer doing math on very large numbers) were present back then as well, even if it was not noticeable.
Then you should know these should have addressed earlier when the source code released back in April 2002.
Here, I'm suggesting ways in relation to the procedural planet surface generator as the thread starter mentioned.
Aww, that sounds like the kind of things that can't be fixed. :(
(in particular if I'm the only one with use for that) :lol:
If you were to fix things, it will likely take longer.
-
I have no clue what you're trying to say to me, I'm just wondering that olde Retail exes were able to do something FSO can't (rendering the 12000km Earth model without trouble).
There are many variables at play here. FS2 ran on very different graphics APIs, on very different hardware; the basic issues that cause rendering errors in FSO (that is, floating point inaccuracies being multiplied over and over by the renderer doing math on very large numbers) were present back then as well, even if it was not noticeable.
Then you should know these should have addressed earlier when the source code released back in April 2002.
And? :wtf: Are you blaming The_E for not having fixed :v-old: bugs before releasing the source code??
Aww, that sounds like the kind of things that can't be fixed. :(
(in particular if I'm the only one with use for that) :lol:
If you were to fix things, it will likely take longer.
I can't code so it'll take like, forever.
TL;DR 2 good reasons to follow your personal warning. :rolleyes:
*words*
Bryan, you're doing that thing again where you are saying words with no understanding of what they mean. Stop it.
And by "stop it", I mean "do not post in this thread again". Noone has the time or patience to keep to explaining to other people why and how you're wrong (since explaining it to you doesn't seem to work).
-
I have no clue what you're trying to say to me, I'm just wondering that olde Retail exes were able to do something FSO can't (rendering the 12000km Earth model without trouble).
There are many variables at play here. FS2 ran on very different graphics APIs, on very different hardware; the basic issues that cause rendering errors in FSO (that is, floating point inaccuracies being multiplied over and over by the renderer doing math on very large numbers) were present back then as well, even if it was not noticeable.
Then you should know these should have addressed earlier when the source code released back in April 2002.
And? :wtf: Are you blaming The_E for not having fixed :v-old: bugs before releasing the source code??
Aww, that sounds like the kind of things that can't be fixed. :(
(in particular if I'm the only one with use for that) :lol:
If you were to fix things, it will likely take longer.
I can't code so it'll take like, forever.
TL;DR 2 good reasons to follow your personal warning. :rolleyes:
*words*
Bryan, you're doing that thing again where you are saying words with no understanding of what they mean. Stop it.
And by "stop it", I mean "do not post in this thread again". Noone has the time or patience to keep to explaining to other people why and how you're wrong (since explaining it to you doesn't seem to work).
Nightmare, when you mentioned "experiences of someone who's been frequently playing with huge things," you overlooked my attempt to play with huge things involving fighter speeds at 500 m/s and capships at 350 m/s (besides the other one who called himself MetalDestroyer77).
It was my mistake of saying words without understanding of what they mean to you all.
-
Aww, that sounds like the kind of things that can't be fixed. :(
(in particular if I'm the only one with use for that) :lol:
There are some ways to reduce the effects of floating point inaccuracies while rendering the game but that still leaves the physics code which still only uses single precision floating point numbers so even if the rendering code could handle larger distances from the origin, the physics engine would still break down.
And again, there are ways to improve this by using higher precision data types for doing physics but that would come at a performance cost and a huge amount of changes required to make it work so it is highly unlikely that this will ever be done.
-
Guess I'll have to stick with having the same modell 2 or 3 times then. But as long as I keep the tbls for them in a TBM instead of the main table I don't feel that bad about it anymore, anyway. :D Certainly one of the things where coders find better things to spend their FreeTime with. :)
@Bryan: I did not say that other people tried it before, but none of them are currently active AFAIK.
-
@Nightmare, but I am the only one active.
Aww, that sounds like the kind of things that can't be fixed. :(
(in particular if I'm the only one with use for that) :lol:
There are some ways to reduce the effects of floating point inaccuracies while rendering the game but that still leaves the physics code which still only uses single precision floating point numbers so even if the rendering code could handle larger distances from the origin, the physics engine would still break down.
And again, there are ways to improve this by using higher precision data types for doing physics but that would come at a performance cost and a huge amount of changes required to make it work so it is highly unlikely that this will ever be done.
@m!m, why not re-write the physics code so it doesn't use arbitrary precision floating point numbers? Plus, it supports third party engines.
-
Bryan. I told you to stop posting in this thread. You're wrong and not contributing anything worthwhile to the discussion.
-
This really interests me, questions about this as I've only just stumbled on the possibility:
Would this mean a transparent collision model for the "ground" that gets textured "chunk" by "chunk" as the player approaches the horizon - that is, can AI ships far in the distance, beyond the rendered ground, collide with the ground?
Would that be exceptionally more or less resource-intensive than a pre-loaded ground texture?
Seems like it would work best for a very non-descript, "flowy" grassland/ocean/desert landscape.
-
That sounds something you could do when you split the ground into several models with LODs or use detail boxes.
-
Bryan. I told you to stop posting in this thread. You're wrong and not contributing anything worthwhile to the discussion.
The E, where can I made this statement? I know this discussion is about the Procedural Planet Surface.
-
:|
(https://i.gifer.com/Dzp3.gif)
-
Bryan. I told you to stop posting in this thread. You're wrong and not contributing anything worthwhile to the discussion.
The E, where can I made this statement? I know this discussion is about the Procedural Planet Surface.
*words*
Bryan, you're doing that thing again where you are saying words with no understanding of what they mean. Stop it.
And by "stop it", I mean "do not post in this thread again". Noone has the time or patience to keep explaining to other people why and how you're wrong (since explaining it to you doesn't seem to work).
Disregard this warning at your peril.
-
So if I understand everything correctly, a procedure plus gravity could easily be scripted in LUA but the tiles would need to be pre-defined POF-files. And there's the danger of the AI crashing into the surface and a whole bunch of graphics issues when flying beyond 100km from the center.
I'm obviously not a programmer, so any ideas I might offer may not be good ones.
Is it possible to create a flag for ground tiles, so when an AI controlled fighter is within x meters from a ground tile, it would change direction in order to avoid collisions?
For instance:
If (fighter X distance to object Y flagged ground tile < Z meters)
Then (fighter X change direction)
Else (operate normally)
Am I also right to assume that if a ground mission is to have ground vehicles like hover tanks (as in Wing Commander 4), they'd need to have pre-defined waypoints and couldn't move freely like fighters can?
-
If (fighter X distance to object Y flagged ground tile < Z meters)
Then (fighter X change direction)
Else (operate normally)
In this form it seems really simple, but in real code this sort of thing is kinda hard to do. For example, what if the fighter's regular behavior makes it want to go below a ground tile? It'd probably keep flip-flopping between the "change direction" behavior and the "normal" behavior.
What if the "change direction" behavior forces the fighter into colliding with another ship? Alternatively, how do we mix the collision avoidance behavior together with the ground avoidance behavior?
I'm sure there's more trouble than what I can think of right now
-
Am I also right to assume that if a ground mission is to have ground vehicles like hover tanks (as in Wing Commander 4), they'd need to have pre-defined waypoints and couldn't move freely like fighters can?
Ground vehicles are a whole other layer of complexity, starting with the fact that they can only rotate around 2 axes instead of 3 and that their pitch and roll need to be matched to whatever surface they're currently on.
Is it possible to create a flag for ground tiles, so when an AI controlled fighter is within x meters from a ground tile, it would change direction in order to avoid collisions?
The FreeSpace AI is hilariously bad at not colliding with things as it is. Sorting that part out would have to take priority over implementing special ground-avoidance behaviour; in fact, ground avoidance would be a side-effect of such work.
-
Some random ideas on collision avoidance vs ground.
It could be done with SEXPs like this one - https://www.hard-light.net/forums/index.php?topic=87880.msg1871458#msg1871458
Unless you're using a flat plain, you'd need to prepare the terrain model with an annoying amount of subsystems that could be used as "bounce-off" points.
On the other hand you could think about "collision avoidance spheres". For smaller craft a simple radius/distance-based system that uses coordinate/orientation-manipulation magic that forces one (or both) ships to alter their paths manually.
For capital ships it would be more complicated, but somebody made something called "auto spread shields" which also generate spheres around the ship that could serve a similar purpose (like "when fighter XY enters this sphere perfom maneuver that directs it away"). The way they are made it doesn't look like it would be benefitial for the performance of the engine though.
-
I just teleport ships upward when their Y coordinates get too low. Awkward when players notice, but not as awkward as head butting the ground forever.