SpaceSimCentral

s2odan wrote:
there's some code in geosphere.frag shader that Tom wrote where he uses : vec3 eyepos = vec3(gl_TexCoord[0]);"eyepos" that is exactly how it seems to react, but I have no prior experience with glsl and opengl so I have no idea if thats normal
That doesn't look correct. We don't seem to actually have texture coordinates for our GeoSphere patches and so I have no idea what would be in gl_TexCoord right then probably complete crap."eyepos" should probably be set using the camera position, although that's complicated in Pioneer I bet, as a uniform vec3 and not actually change per-vertex like it would if set from the gl_TexCoord... if we were actually setting that anywhere [/hr]Ignore me I'm retarded, hadn't properly read the ".vert" file it's just passing the results of this transform through using the tex coords
Code:
gl_TexCoord[0] = gl_ModelViewMatrix * gl_Vertex;
Although that does still seem strange since the "eyepos" will change for each vertex and if the combined modelview matrix changes, which it will, when you move it. I wonder if "eyepos" is either misnamed or if this is actually a bug and passing in a fixed position will actually fix your problem?

the specific camera angle what are the options for potential changes ?

Back to spaceway, Artlav pretty simply stated that he solved the GPU/CPU problem by "using the same mathematics on both". I think he didn't even really notice there was a problem. I guess it all comes down to wheather you can pack your math into a format that is equally processable by CPU and GPU.He mentioned something about initial problems with craters, which he created via a homebrewn lookup table, which he eventually redid with Voroni. After that, they also provided equal results.

s2odan wrote:
hey, sorry I forgot about this question Heres what the values mean::seed(1900) - A number used in the creation of all random numbers this planet uses(It changes everything):radius(f(38,100)) : 0.38 Earth Radii:mass(f(55,1000)) 0.055 Earth Masses:temp(340) 340 Kelvin:semi_major_axis(f(387,1000)) Average orbitral distance.. hmm shit I forget what the units here are.. Ah scratch that Im pretty sure its in AUs:eccentricity(f(205,1000)) Higher values give a more eliptical orbit:inclination(math.deg2rad(7.0)) the bodies inclination, how much it is on its side. Or infact that may be Axial tit, one is how much on its side the object is, the other is how far off the eliptical plane the objects orbit is.:rotation_period(f(59,1)) How long it takes to rotate/spin in days I thinkThe rest are self-explanatory.To find the number in Fixed() terms, just divide the first by the second::ice_cover(f(2,100)) = 0.02:metallicity(f(9,10)) = 0.9 ect ect
Quote:
beetlegeuse, sirius, proxima,rigel kentaurus ect
We have them all. Please note that its likely any randomly created systems will not be included, we use a real starmap so there is no need to make stars up. FYI FFE and Frontier had wildly inaccurate starmaps, we aren't following that route ;)EDIT/// just to clarify, there's absolutely nothing wrong with giving already existing systems interesting features, But I got the impression you were looking to create starsystems that aren't there. Which is the wrong way to go about it as the majority of stars are all included, its just that they are now in their correct places. (3d vs 2d)
cheers for that mate ........actualy i wasnt looking to add new ones just create planets round the existing lol

Greeting everyone.Sorry if i'm not exactly up to speed, but my friend redirected me here while asking questions, so i thought direct talk would be more productive.In Spaceway there are 2 functions for each planet - elevation by 3D position and colour by 3D position.Colour function use the output of the height function, sometimes more than once (to determine slope for example).Both functions are implemented on both CPU and GPU.So, when the textures are generated on GPU, for each point of the slice the terrain function is evaluated, then the color function is evaluated base on the result.The output is a segment of texture which is applied to the mesh.The mesh itself is always CPU generated.GPU is quite loose with float numbers packed into a texture, and i always got the steppy mesh if i tried - you can see this in the GPU generated textures being slightly off the actual mesh.The mesh is a simple grid, unchanged for anything. The elevation function result is applied to every vertex. This is always done on CPU.Both functions are exactly synced up, so there is no discrepancy.Further problems with using GPU for generating the mesh/heights is collision detection and instrumentation.On CPU, these can just call the elevation function.On GPU it becomes unhealthy complicated, if possible at all.Orulex is the origin of that terrain engine, Spaceway is it's evolution.There never were any generate-heightmaps-to-texture-and-enlarge-pixels things, only terrain function directly applied to first ROAM, then later cubic sphere grid.Orulex used a virtual machine with an arbitrary function code compiled into a bytecode, Spaceway uses a restricted set of configurable models compiled into native code.If there is anything i can help with, ask away, i'll be around.

@Artlav,For collision we only need to check for a single position above the surface. At worst perhaps a small number per frame. That we can easily do CPU side.What do you think to the idea of doing all terrain height and normal generation on the GPU using render to texture? Then do texture splatting in a shader using the height and normal maps?Does that side reasonable? Have you ever tried anything like it?Andy

Hi Artlav, and welcome to our little corner :)Thanks for taking the time to set us straight on a few things.
Quote:
The mesh itself is always CPU generated.
Am I correct in thinking this is your bottleneck? I guess its likely why I experienced identical load times for the terrain with GPU active or inactive, not taking textures into account of course.I always thought it was next to impossible to generate two identical terrains one on CPU and the other on GPU, so this at least opens up some possibilities. I/we was/were originally planning on generating a basic terrain on CPU, and then if the user has hardware to suport it, add further tesselation of the terrain using an implementation of perlin noise we have for the GPU. Do you have a GLSL implementation of Perlin noise? I wasn't able to find one in the Spaceway source, all I stumbled upon was alib\noise.pasThis is the implementation of perlin I have been using on the GPU: https://github.com/ashima/webgl-noise/wiki

s2odan wrote:
This is the implementation of perlin I have been using on the GPU: https://github.com/ashima/webgl-noise/wiki
That's the same one I've been looking at, however nVidia also give away an "inoise.fxh" file which I found the other day. It would need porting to GLSL but that seems quite doable and I have it for when I go away tomorrow to play with.There's a slightly different version of it here: Procedural Golf terrain generator ... no I'm not making that link up

What is it about this forum thread and ninjas?
Quote:
What do you think to the idea of doing all terrain height and normal generation on the GPU using render to texture?
I was told there's a reason we can't do that.. I'm not remembering what it was though Beer, weed and programming, interesting combination
Quote:
nVidia
Well if they wrote it as competently as their drivers, I think I'll be stepping around that one But good luck with it, and have fun while away

fluffyfreak wrote:
What do you think to the idea of doing all terrain height and normal generation on the GPU using render to texture? Then do texture splatting in a shader using the height and normal maps?Does that side reasonable? Have you ever tried anything like it?

Render a heightmap to texture produces a steppy mesh, a way of generating and rendering a mesh directly on a GPU in it's entirety is not something i know how to do.Rendering to a texture, then passing the texture to the mesh-making shader sounds like a PhD in perversions.Might actually work quite a lot faster with big textures being used, no idea here.Does not cancel out the precision problem.
s2odan wrote:
Am I correct in thinking this is your bottleneck? I guess its likely why I experienced identical load times for the terrain with GPU active or inactive, not taking textures into account of course.

Not by a very long shot. The biggest bottleneck is the texture generation.The mesh is actually the most trivial of it all, computation-wise.The textures and the mesh are generated asynchronously, and the mesh is always ready by the time textures arrive.It may not be the fastest way of making the mesh, but in perspective it's not the biggest problem there is.By the way, even on the slowest rig i tried it, it takes a few seconds from zero to full mesh, and on the higher-end ones it's usually under a second.Is that different for you? What hardware is it different on?
s2odan wrote:
I always thought it was next to impossible to generate two identical terrains one on CPU and the other on GPU, so this at least opens up some possibilities. I/we was/were originally planning on generating a basic terrain on CPU, and then if the user has hardware to suport it, add further tesselation of the terrain using an implementation of perlin noise we have for the GPU. Do you have a GLSL implementation of Perlin noise? I wasn't able to find one in the Spaceway source, all I stumbled upon was alib\noise.pas

Look for texgpu.pas. Both implementations have nearly-identical looking code.Perlin is not exactly the hardest thing there is to port to GPU.Once again, only one version would be optimised to the limit at the expense of the other.There is nothing impossible about it, all you need is to carefully sync the base functions - trimming, gradients, rounding, noise functions, square root handling, and so on.Different GPUs tend to handle edge cases differently.

Quote:
Not by a very long shot. The biggest bottleneck is the texture generation.The mesh is actually the most trivial of it all, computation-wise.
I should have been more specific and probably written that differently I mean not taking textures into account, basically I should have said: which is slower in spaceway, generating the noise/height levels or generating the mesh? Because the mesh itself seemed to load at the same speed no matter if I chose GPU or CPU, as if the actual generation of height values was no faster OR slower on the GPU.Just trying to get a feel for how you do this in Spaceway, in Pioneer we use a lot of octaves of noise as such generating the mesh is not so trivial and tends to take a little while from the tests I have ran. But we probably use too much noise for some of the terrains in Pioneer. In pioneer if we were able to export that to the GPU, we would be seeing drastic increases in speed. (If it could even handle that many octaves)
Quote:
By the way, even on the slowest rig i tried it, it takes a few seconds from zero to full mesh, and on the higher-end ones it's usually under a second.Is that different for you? What hardware is it different on?
It felt a couple of seconds for the terrain itself (Not including textures). As I mentioned the speed was identical with GPU option active as with it off. (Again, not including textures as they were a lot faster with GPU active).Thats on a stock Q6600 with a Gtx285.
Quote:
Look for texgpu.pas. Both implementations have nearly-identical looking code.
Cheers.

s2odan wrote:
which is slower in spaceway, generating the noise/height levels or generating the mesh?.
Not sure how to distinguish the two - the mesh is generated with the height/terrain.The time it takes to make the mesh (i.e. define the vertices, compute normals and rotate) is negligible compared to the time for elevation function evaluation.Either we are not on the same terminology here, or you ask the question literally.In case of the latter, the answer is above and below.System-wide, complexity from worst to simplest, top down:-Terrain textures-Vessel generation-Starfields-Terrain elevation-Surface props generation-Terrain tessellation-Terrain meshes-Autopilots-Physics
s2odan wrote:
Because the mesh itself seemed to load at the same speed no matter if I chose GPU or CPU, as if the actual generation of height values was no faster OR slower on the GPU.

Height for the mesh is generated entirely on CPU, so i won't expect a difference.If you have only one CPU core, there will be one due to time being shared between textures and terrain, but not on multi-cores.
s2odan wrote:
Just trying to get a feel for how you do this in Spaceway, in Pioneer we use a lot of octaves of noise as such generating the mesh is not so trivial and tends to take a little while from the tests I have ran. But we probably use too much noise for some of the terrains in Pioneer. In pioneer if we were able to export that to the GPU, we would be seeing drastic increases in speed. (If it could even handle that many octaves)

I felt that if you want to generate a real planet, you better do it good.I couldn't do it good and fast at once, so i opted for a cartoonish kind of planets instead - single biome, no variety in features.Several bands of detalisation, microterrain near the bottom, a few broken microtexture attempts to enhance eye-level stuff (like http://orbides.1gb.ru/sway/sway-090917-0.jpg ), and that's about it.Neither band uses many octaves, but there are many bands.Maybe it evens out, i don't know.

Quote:
Either we are not on the same terminology here, or you ask the question literally.
Hehe, I admit I'm not so great with terminology However you answered the question well enough.
Quote:
Height for the mesh is generated entirely on CPU, so i won't expect a difference.
Cool, so I'm not going mad :)The results and my checking of the code indicated as such, but I was informed to the contrary.
Quote:
I felt that if you want to generate a real planet, you better do it good.I couldn't do it good and fast at once, so i opted for a cartoonish kind of planets instead - single biome, no variety in features.
I know what you mean, but you've still done a good job. We decided on detail a while back, which of course means our terrrains are slow... I am seriously considering adopting a very similar technique as you use here. For a start we don't have 'proper' textures, they are only per-vertex colour variations, not a texture in the proper term as far as I understand the terminology.What I mean by this is that likely we will reduce detail for the mesh, and also port our current colour code to actually use proper textures and co-ordinates (render to texture), and put more detail into the textures.I have also considered further warping of the mesh via the GPU for aesthetics only. These would also be small changes in height and slope so as not to require an update of the collision mesh.This will work for Pioneer where you cannot leave your spaceship, But most likely it would break features in Spaceway, as you can leave your ship and drive a car... It would not feel right to drive *through* bumps.Did you ever try that despite its negative effects on the collison mesh ? (further warping of the mesh by the GPU)
Quote:
Several bands of detalisation, microterrain near the bottom, a few broken microtexture attempts to enhance eye-level stuff (like http://orbides.1gb.ru/sway/sway-090917-0.jpg ), and that's about it.
Hehe well you may call them 'broken', but they are still very effective. I like the patterns, the one you linked to seems to make use of a crater function. (The dark rounded indents).Cheers.

Anyway back on topic Here's another update to the star shader work, some animated sunspots which run rather quick too, ignore the 30fps in the video, thats fraps locking the framerate because why would you need a 60fps video? Thats on a half decent video card though (gtx285), I'd be interested to see how it performs on other cards.

s2odan wrote:
For a start we don't have 'proper' textures, they are only per-vertex colour variations, not a texture in the proper term as far as I understand the terminology.

Yes, that explains the focus on mesh generation.In my case the vertices are all white and textures do the business, so the mesh is an afterthought.
s2odan wrote:
I have also considered further warping of the mesh via the GPU for aesthetics only. These would also be small changes in height and slope so as not to require an update of the collision mesh.This will work for Pioneer where you cannot leave your spaceship, But most likely it would break features in Spaceway, as you can leave your ship and drive a car... It would not feel right to drive *through* bumps.Did you ever try that despite its negative effects on the collison mesh ? (further warping of the mesh by the GPU)

That would hardly break anything, since collision detection is done against the function, not the mesh. So, if the post-warping is added to the terrain function, the car would bounce on the bumps nicely.Never tried that, however.What i did try is to generate the terrain live - each pixel on screen is an evaluation of the color&terrain function instead of mesh&texture.Was at about 4 FPS, and the picture "swam" from excessive sub-pixel details.With some fixing it might be perfect in half a decade or so when hardware catch up, but now that does not even look nice.

Terrains have been getting an overhaul, we're reducing the amount of noise we use to build a terrain but still trying to get the same effect, more for less :)Here are some strange new asteroid/small moon terrains:Cool crater:I don't know what this is, beehive planet maybe : Cheers.

Very cool, I will be looking for these in the next vid.

bchimself wrote:
Very cool, I will be looking for these in the next vid.
They're not in alpha 18, or even a nightly yet. They'll probably make it to alpha 19 if s20dan finishes them in time.

robn wrote:


bchimself wrote:
Very cool, I will be looking for these in the next vid.
They're not in alpha 18, or even a nightly yet. They'll probably make it to alpha 19 if s20dan finishes them in time.
Acknowledged.

The 3rd and 4th pics have got me really excited. Nice work s2odan! So am I right in thinking you are achieving these improved visuals without needing a gpu upgrade?