Well that was hilariously difficult and error prone but I now have encoded and packed normal, specular and AO maps, plus diffuse + it's greyscale version (for trying to sort the triplanar blending).
Think I will calculate the slope/height values next and then try some simple blending between the two texture sets based on the slope.
Asteroid(s)
-
- Posts: 1343
- Joined: Tue Jul 02, 2013 1:49 pm
- Location: Beeston, Nottinghamshire, GB
- Contact:
-
- Posts: 1343
- Joined: Tue Jul 02, 2013 1:49 pm
- Location: Beeston, Nottinghamshire, GB
- Contact:
Re: Asteroid(s)
Oh I wouldn't worry about that, real life is too important.nozmajner wrote:I'm thinking too much I'm afraid. :)
If you do want to get out of a rut or you're feeling a little less than productive though then I recommend just hacking stuff together, ignoring all the details and just trying stuff out.
Quite often I throw stuff away entirely and never use it - it's purpose is just to show me how stuff might work. Other times I'll make something new based on the same ideas, lifting bits wherever I can from that prototype.
Mostly you guys only get to see the finished code ;)
Re: Asteroid(s)
Here are the parameters for Halley's commet, from wikipedia.impaktor wrote:I'll see if I can add a rockyworld with correct parameter for Halley's comet (in the coming days)
Code: Select all
local halleys_commet =
CustomSystemBody:new('Halley\'s Commet', 'PLANET_ASTEROID')
:eccentricity(f(9.67,10)) -- 0.967
:mass(f(36.83,1000000000000)) -- 2.2e14 kg / 5.97219e24 kg
:semi_major_axis(f(178,10)) -- 17.8 AU
:rotation_period(f(2.2,1)) -- 2.2 d siderial rotation
:radius(f(8.632,10000)) -- 15x8 km, mean radius 5.5 km / 6771 km
:life(f(0,1)) -- only scientologists
:orbital_phase_at_start(fixed.deg2rad(f(10,1))) -- TO-DO
s:bodies(sol, {
halleys_commet,
mercury,
...
-
- Posts: 1343
- Joined: Tue Jul 02, 2013 1:49 pm
- Location: Beeston, Nottinghamshire, GB
- Contact:
Re: Asteroid(s)
Nice work impaktor :)
I guess we will want a way to have them filtered from the System Info / view displays or change how they're shown.
I guess we will want a way to have them filtered from the System Info / view displays or change how they're shown.
-
- Posts: 1343
- Joined: Tue Jul 02, 2013 1:49 pm
- Location: Beeston, Nottinghamshire, GB
- Contact:
Re: Asteroid(s)
Uploaded some new screenshots of the asteroid using a test seed to create it the same way every time.
This has let me optimise the generation a bit but it's probably not going to be something we can afford to do in the main thread so integrating it with the engine proper will be interesting.
I took 3 screenshots using each of the lighting options in the modelviewer where I have been testing it.
I've got some work to do exposing the controls for the texturing and stuff before it's ready for tinkering but getting closer now.
Andy
This has let me optimise the generation a bit but it's probably not going to be something we can afford to do in the main thread so integrating it with the engine proper will be interesting.
I took 3 screenshots using each of the lighting options in the modelviewer where I have been testing it.
I've got some work to do exposing the controls for the texturing and stuff before it's ready for tinkering but getting closer now.
Andy
-
- Posts: 1343
- Joined: Tue Jul 02, 2013 1:49 pm
- Location: Beeston, Nottinghamshire, GB
- Contact:
Re: Asteroid(s)
Recent progress has been adding a domain warped noise which is blended with the vertical surfaces so you get jagged slopes and smooth flat areas.
This wasn't high enough resolution so I switched to using 32-bit indices during the generation of the icosahedron meshes.
This wouldn't work elsewhere in the game or for rendering but after welding of duplicate vertices it reduces the number of vertices to less than 65536 which means I can then convert the indices back into Uint16.
That gives me an extra two levels of subdivision compared to the usual Drawables::Sphere class and a high enough resolution mesh to work with, a neat trick anyway.
There was some experimenting with blending but I've not yet taken a serious look at it.
Collision and integration with the engine proper still needs works but I have done some hacking to experiment with generating the collision information, this leads me to believe that I will need to properly integrate the generated asteroid with the scenegraph rendering system.
In hindsight that's a really obvious idea/statement but it's surprising how long good ideas take to penetrate my mind!
Currently, and in part because of the scenegraph realisation, I am working on a system to easily generate LODs.
Which means that the current order of tasks for the asteroid visuals / collision is something like:
There are currently a number of things that can be changed, for example:
None of these are exposed yet, nor do they have any guidance for setting their values.
This is all before we start on actually placing them in the game world.
I was hoping that someone might find that interesting, writing the location/information generation stuff for asteroids belts, rings, Trojans and loose wandering bodies etc :/ oh well, I'll just have to get around to it after the rest.
Andy
This wasn't high enough resolution so I switched to using 32-bit indices during the generation of the icosahedron meshes.
This wouldn't work elsewhere in the game or for rendering but after welding of duplicate vertices it reduces the number of vertices to less than 65536 which means I can then convert the indices back into Uint16.
That gives me an extra two levels of subdivision compared to the usual Drawables::Sphere class and a high enough resolution mesh to work with, a neat trick anyway.
There was some experimenting with blending but I've not yet taken a serious look at it.
Collision and integration with the engine proper still needs works but I have done some hacking to experiment with generating the collision information, this leads me to believe that I will need to properly integrate the generated asteroid with the scenegraph rendering system.
In hindsight that's a really obvious idea/statement but it's surprising how long good ideas take to penetrate my mind!
Currently, and in part because of the scenegraph realisation, I am working on a system to easily generate LODs.
Which means that the current order of tasks for the asteroid visuals / collision is something like:
- LOD mesh creation
- SceneGraph integration
- Collision creation & setup
- Integration with AsteroidBody for use in-game (rather than just modelviewer)
- Config file to control textures used and tiling
- Further surface deformation (optional) (Small craters?)
- Decoration eg: additional rocks/boulders on the surface etc (optional)
There are currently a number of things that can be changed, for example:
- blending used to choose between the surface normal and the sphere normal, bigger asteroids would be more spherical so it would be weighted towards the sphere normal instead of the surface normal like for smaller asteroids.
- deformation amount controls the depth of the deformation, small objects can be deformed much more than big ones.
- deformation radius controls the size of the area affected by each deformation, but does this want to be bigger or smaller depending on the size of the world and how is it constrained or chosen?
None of these are exposed yet, nor do they have any guidance for setting their values.
This is all before we start on actually placing them in the game world.
I was hoping that someone might find that interesting, writing the location/information generation stuff for asteroids belts, rings, Trojans and loose wandering bodies etc :/ oh well, I'll just have to get around to it after the rest.
Andy
-
- Posts: 1343
- Joined: Tue Jul 02, 2013 1:49 pm
- Location: Beeston, Nottinghamshire, GB
- Contact:
Re: Asteroid(s)
As ever other developers are of course blowing away absolutely all of my very best efforts ;)
Enemy Starfighter : Doing asteroid tests in different environment themes.
Enemy Starfighter : Doing asteroid tests in different environment themes.
Re: Asteroid(s)
Those Enemy Starfigher ones are very nice, but they seem to be hand sculpted.
Re: Asteroid(s)
Since we were talking about texture and details of asteroids:
Rosetta catches its own shadow
"The highest resolution image yet taken of Comet 67P by the Rosetta satellite has just been released."
Rosetta catches its own shadow
"The highest resolution image yet taken of Comet 67P by the Rosetta satellite has just been released."
-
- Posts: 1343
- Joined: Tue Jul 02, 2013 1:49 pm
- Location: Beeston, Nottinghamshire, GB
- Contact:
Re: Asteroid(s)
That is an option too, I don't see us having a single procedural generator to cover all situations.nozmajner wrote:Those Enemy Starfigher ones are very nice, but they seem to be hand sculpted.
Having a set of asteroids models that we can apply a variety of textures too might be another useful way of producing them.
Perhaps we could "splat" some decals on or customise the geometry in some circumstances too.
This has all been a valuable learning exercise for me and I'm quite far along, almost able to use it in the game itself but progress has slowed lately due to work and real-life!
Hopefully I'll be able to get back too it soon.
Andy