Hi, Michalis!
This is not anywhere near "haste" topic. But I'd be very thankful for your comments on the issue.
The idea is:
When I'll come to implementation of Overworld I have an idea to put it on a surface of a spherical world. I.e. we have a planet and a huge Overworld over its surface. We have a Sun and other planets which position is calculated to generate sky map, day-and-night cycle, etc. Maybe, even some dynamic weather system to allow for sky generation and gradual meteorologic conditions change.
This is not a complete planet, as one would expect in a starflight simulator, however, it may have a lot of similarities.
The situation is:
At this point the Overworld consists of NxM chunks, so that each chunk may be managed independently. Each chunk consists of terrain + static objects + dynamic objects.
I don't think there is a need to make it cyclable (thou it's tempting :)), so the "map" of the Overworld would be quais-2D, it just has to be a bit curvy. The Overworld is still small relative to Planet size, so it's mostly to implement natural "horizon" to hide remote objects behind depending on camera height above the ground.
If the world is spherical, then we have a GravityUp vector3 differen in different areas of the Overworld. Actually, one GravityUp for a chunk should be enough.
The problem is:
Will the terrain understand GravityUp engine-side or can it be game-side adjusted to?
Can the terrain be seamlessly generated in these conditions engine-side, or will I have to make a manual generation algorithm? Yes, there will be a manual algorithm: I need to process the Terrain (e.g. smooth Perlin to build a town, make mountains and make errosion for rivers and lakes), but for now I'm just wondering if I can use some already available options, or should I just make everything from a scratch.
How will SceneManager and other Engine routines behave if different items would have different GravityUp and UpPrefer?
Any other issues with the Engine I can run into by toying with GravityUp and spherical/chunked world?
Last edit: EugeneLoza 2017-08-09
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Will the terrain understand GravityUp engine-side or can it be game-side adjusted to?
Can the terrain be seamlessly generated in these conditions engine-side, or will I have to make a manual generation algorithm?
Hm, I'm not sure do I understand these questions, because I'm not sure what you mean by "terrain" here?
If you mean our current CastleTerrain unit, it simply generates a heightmap in 2D. You can use it's TTerrain.CreateNode method to get this terrain as X3D Shape, that spans in XZ and is lower/higher in Y (just like X3D ElevationGrid). So it's not concerned by the GravityUp assigned anywhere.
How will SceneManager and other Engine routines behave if different items would have different GravityUp and UpPrefer?
Right now, all the items within a single TCastleSceneManager (which equals to "within a single T3DWorld") must have the same GravityUp vector. Simply because GravityUp is just defined in T3DWorld.
However, when I was coding this, I was actually thinking about making some day a spherical world, a game played on a small planet/asteroid. It is possible to make the gravity direction that even changes depending on your position. E.g. adding to T3DCustomTransform a method like "CurrentGravityUp", that by default returns "World.GravityUp", but can be overriden to return anything (it may even be calculated based on current T3DCustomTransform.Position). And replace two calls to "World.GravityUp" with "CurrentGravityUp".
However, this was never tested by me in practice. Possibly, it's a crazy idea :), leading to a lot of problems that are hard to solve. In which case, I do not want to complicate the engine with this. A myriad of modern AAA games show that you can have huge planet-like worlds on a flat surface :)
But maybe it's easy to do and fun? I really have no idea, and it looks like you may test it sooner than me :)
In principle it should work. No calculations actually assume that gravity is constant throughout the world.
Some collision stuff uses "GravityCoordinate", which does not allow gravity to be any 3D vector. It must be a vector along the axis X, Y or Z. This assumption is for efficiency. If your gravity vector is different, some collisions may be incorrect, and e.g. creatures may float above the ground.
To be honest, I don't know how easy/hard it will be to fix it. Maybe it's a big problem, maybe it's trivial, maybe it can even be ignored to some extent.
Any other issues with the Engine I can run into by toying with GravityUp and spherical/chunked world?
This is unrelated to gravity, but it's related to huge worlds:
Remember that the Single type is fast, but it's not the most precise type ever. It's not precise enough if you really want to express positions on planet-size (like Earth-size) scale.
<sidenote>
X3D folks who designed "geospatial" nodes (they allow to express positions using latitude/longitude, which is more comfortable for a planet than X/Y/Z), use Double to express coordinates. See http://www.web3d.org/documents/specifications/19775-1/V3.2/Part01/components/geodata.html and "25.2.5 Dealing with high-precision coordinates" section there if you're interested.
We do not implement the X3D Geospatial nodes for now, so I'm only linking to it here as something possibly interesting to read :) None of this works in our engine for now, and it's probably not needed for a game engine at all.
</sidenote>
You specifically wrote that your chunks do not "add up" to a whole planet... so you're probably OK. But be careful with this. If you try to model a really huge world, you may run into problems with precision, and you may need to store things with Double precision (or Extended, which is even more precise than Double, but only exists on some platforms; on others, Extended = Double).
Moreover, you will need to deal with the fact that the engine mostly uses Single-precision internally. So you will need to only "feed" the engine a subset of your data, possibly shifted. (Well, you probably don't want to add a whole detailed planet model to SceneManager.Items anyway :) )
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks a lot!
Now I have a food for thought :)
About "huge" - it's huge corresponding to a "normal" location size (~100-300 thousands tris). E.g. 10x10 km, maybe 20x20km (3 hours of walking in real-life), so pricision is not a serious issue here. But creating a real horizon would actually make a ~10-story building go behind the horizon - this is mostly the only thing I'm trying to solve this way :), to be more precise: 3m drop for 10km, 21m drop for 20 km, 55m drop for 30km (larger valules for "farland").
On the other hand... well, considering an uneven terrain this is also a non-critical issue, most users won't even notice :) So, if this is something that can harm performance, then it's defnintely not worth it.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
a long long time ago, i did this by having the whole world in a transform and rotating it as the avatar moved. (cortana or blaxxun browser i think) basically worked, but as with any pushing against the usual way to do it, i found a bug; occasionally you would fall throught the solid geometry, i guessed the test for falling was being confused by the geometry moving throught the avatar rather than the usual reverse.
FWIW i always felt that, given the name .wrl (world) and the utility of it, VRML should have had this as a supported mode, even as the default on
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi, Michalis!
This is not anywhere near "haste" topic. But I'd be very thankful for your comments on the issue.
The idea is:
When I'll come to implementation of Overworld I have an idea to put it on a surface of a spherical world. I.e. we have a planet and a huge Overworld over its surface. We have a Sun and other planets which position is calculated to generate sky map, day-and-night cycle, etc. Maybe, even some dynamic weather system to allow for sky generation and gradual meteorologic conditions change.
This is not a complete planet, as one would expect in a starflight simulator, however, it may have a lot of similarities.
The situation is:
At this point the Overworld consists of NxM chunks, so that each chunk may be managed independently. Each chunk consists of terrain + static objects + dynamic objects.
I don't think there is a need to make it cyclable (thou it's tempting :)), so the "map" of the Overworld would be quais-2D, it just has to be a bit curvy. The Overworld is still small relative to Planet size, so it's mostly to implement natural "horizon" to hide remote objects behind depending on camera height above the ground.
If the world is spherical, then we have a GravityUp vector3 differen in different areas of the Overworld. Actually, one GravityUp for a chunk should be enough.
The problem is:
Will the terrain understand GravityUp engine-side or can it be game-side adjusted to?
Can the terrain be seamlessly generated in these conditions engine-side, or will I have to make a manual generation algorithm? Yes, there will be a manual algorithm: I need to process the Terrain (e.g. smooth Perlin to build a town, make mountains and make errosion for rivers and lakes), but for now I'm just wondering if I can use some already available options, or should I just make everything from a scratch.
How will SceneManager and other Engine routines behave if different items would have different GravityUp and UpPrefer?
Any other issues with the Engine I can run into by toying with GravityUp and spherical/chunked world?
Last edit: EugeneLoza 2017-08-09
Hm, I'm not sure do I understand these questions, because I'm not sure what you mean by "terrain" here?
If you mean our current CastleTerrain unit, it simply generates a heightmap in 2D. You can use it's TTerrain.CreateNode method to get this terrain as X3D Shape, that spans in XZ and is lower/higher in Y (just like X3D ElevationGrid). So it's not concerned by the GravityUp assigned anywhere.
Right now, all the items within a single TCastleSceneManager (which equals to "within a single T3DWorld") must have the same GravityUp vector. Simply because GravityUp is just defined in T3DWorld.
However, when I was coding this, I was actually thinking about making some day a spherical world, a game played on a small planet/asteroid. It is possible to make the gravity direction that even changes depending on your position. E.g. adding to T3DCustomTransform a method like "CurrentGravityUp", that by default returns "World.GravityUp", but can be overriden to return anything (it may even be calculated based on current T3DCustomTransform.Position). And replace two calls to "World.GravityUp" with "CurrentGravityUp".
However, this was never tested by me in practice. Possibly, it's a crazy idea :), leading to a lot of problems that are hard to solve. In which case, I do not want to complicate the engine with this. A myriad of modern AAA games show that you can have huge planet-like worlds on a flat surface :)
But maybe it's easy to do and fun? I really have no idea, and it looks like you may test it sooner than me :)
In principle it should work. No calculations actually assume that gravity is constant throughout the world.
Some collision stuff uses "GravityCoordinate", which does not allow gravity to be any 3D vector. It must be a vector along the axis X, Y or Z. This assumption is for efficiency. If your gravity vector is different, some collisions may be incorrect, and e.g. creatures may float above the ground.
To be honest, I don't know how easy/hard it will be to fix it. Maybe it's a big problem, maybe it's trivial, maybe it can even be ignored to some extent.
This is unrelated to gravity, but it's related to huge worlds:
Remember that the Single type is fast, but it's not the most precise type ever. It's not precise enough if you really want to express positions on planet-size (like Earth-size) scale.
<sidenote>
X3D folks who designed "geospatial" nodes (they allow to express positions using latitude/longitude, which is more comfortable for a planet than X/Y/Z), use Double to express coordinates. See http://www.web3d.org/documents/specifications/19775-1/V3.2/Part01/components/geodata.html and "25.2.5 Dealing with high-precision coordinates" section there if you're interested.
We do not implement the X3D Geospatial nodes for now, so I'm only linking to it here as something possibly interesting to read :) None of this works in our engine for now, and it's probably not needed for a game engine at all.
</sidenote>
You specifically wrote that your chunks do not "add up" to a whole planet... so you're probably OK. But be careful with this. If you try to model a really huge world, you may run into problems with precision, and you may need to store things with Double precision (or Extended, which is even more precise than Double, but only exists on some platforms; on others, Extended = Double).
Moreover, you will need to deal with the fact that the engine mostly uses Single-precision internally. So you will need to only "feed" the engine a subset of your data, possibly shifted. (Well, you probably don't want to add a whole detailed planet model to SceneManager.Items anyway :) )
Thanks a lot!
Now I have a food for thought :)
About "huge" - it's huge corresponding to a "normal" location size (~100-300 thousands tris). E.g. 10x10 km, maybe 20x20km (3 hours of walking in real-life), so pricision is not a serious issue here. But creating a real horizon would actually make a ~10-story building go behind the horizon - this is mostly the only thing I'm trying to solve this way :), to be more precise: 3m drop for 10km, 21m drop for 20 km, 55m drop for 30km (larger valules for "farland").
On the other hand... well, considering an uneven terrain this is also a non-critical issue, most users won't even notice :) So, if this is something that can harm performance, then it's defnintely not worth it.
a long long time ago, i did this by having the whole world in a transform and rotating it as the avatar moved. (cortana or blaxxun browser i think) basically worked, but as with any pushing against the usual way to do it, i found a bug; occasionally you would fall throught the solid geometry, i guessed the test for falling was being confused by the geometry moving throught the avatar rather than the usual reverse.
FWIW i always felt that, given the name .wrl (world) and the utility of it, VRML should have had this as a supported mode, even as the default on