Oh wow! That is really nice work.

I can easily imagine a big old sailing ship making it's way across the ocean in those images.

Makes me want to come over all nautical it does! :girlcrazy:

I can easily imagine spindrift flying off that ocean!

I am very jealous of all this fantastic progress you're making Nevil! Congrats on the awesome looking improvements to the engine 🙂

I am very jealous of all this fantastic progress you're making Nevil! Congrats on the awesome looking improvements to the engine 🙂

Hey thank you 😀

 

Completely off-topic from your video, which is awesome by the way, but do you find that you have to force the game to use the nVidia GPU otherwise it chooses the integrated Intel GPU (which is naff) or does everything just work for you?

 

I just ask because I recently found the solution to making it automatically use the dedicated GPU on laptops by adding this in the Pioneer code:

extern "C" {
    // This is the quickest and easiest way to enable using the nVidia GPU on a Windows laptop with a dedicated nVidia GPU and Optimus tech.
    // enable optimus!
__declspec(dllexport) DWORD NvOptimusEnablement = 0x00000001;

    // AMD have one too!!!
    __declspec(dllexport) int AmdPowerXpressRequestHighPerformance = 1;
}

 

BTW this is working, thanks !! this is now part of my engine ->  https://github.com/NevilClavain/DrawSpace/commit/d4ce31c98c15dfceaa24b72c77b96cc5babefe75

A small video, with debug camera sailing on the ocean. Those FPS slowsdown at the middle of video are due to the capture software

[media]https://www.youtube.com/watch?v=NdYSWFv0Bao[/media]

-Nev-

Look upon Nevil's works ye mighty and despair! :girlcrazy:

Amazing video Nevil, I am soooOOOoooo glad you decided to re-visit XFrontier. :queen:

 

Look upon Nevil's works ye mighty and despair!   :girlcrazy:

Amazing video Nevil, I am soooOOOoooo glad you decided to re-visit XFrontier.   :queen:

Thks Geraldine

That being said,what I have long feared just happened today.

This was certainly the last video on a 12000 km diameter planet. I was forced to reduce from 12000 km to 1000 km the planet diameter, due to strong terrain vertices wobbling as the player view is near the ground, which is visually ugly.

Looks like I'm reaching the damn GPU 32 bit float precision limit, and I am totally helpless to find a workaround for it, otherwise 64 bit float for GPU are useless today.

Terrain vertices initial position -before applying world and view matrix- are computed by the vertex shader, and everything else rely on it.

By reducing planet diameter this damn side effect has almost disappeared. Maybe I can grow from 1000 km to 2000 km, have to led some tests again

I'm curious to know how Outerra and INovae engine solved the problem, as they have real sized planets; and what about Pioneer ?

I also noticed that other planet engine has really small sized planet (as is my case now) : No man's Sky, Dual Universe, Star Citizen. Did they faced the same issue ?

[media]https://www.youtube.com/watch?v=fLrpBLDWyCI[/media]

-Nev-

Well in the case of Star Citizen they did the switch to 64 bit so that they could expand their star systems as a whole. Elite still has a 32 bit version but you cant land on the planets. For that, the 64 bit Horizons version is what you need. It seems 32 bits just isn't enough for larger planets with lots of detail. As for Pioneer, I will leave that one for Andy to answer.

**paging Andy**

Andy, please come to the SSC's front desk :girlcrazy:

Hello!  :girlcrazy:

There's probably a better way of explaining this, especially as I'm a bit tired but what we do is move everything around so that it's closer to the camera.

Jitter / vertex wobbling is still technically happening, it's just that it's happening far away from the camera so you don't notice it. 

I tried to explain this some years ago in this blog post, although a lot of Pioneer's rendering and code layout has changed the basic idea is the same.

 

 

push the current matrix and then translate the view according the difference between the camera position and the clipCentroid (which is the centre of the four corner vertices),

• this helps us deal with a problem called “jitter” (/”jittering”) caused by the GPU only using 32-bit floats which aren’t precise enough to represent the terrain. What we do is move the rendering of the patch in such a way that 32-bit’s are precise enough for us by offsetting it from the camera position. We’re effectively moving it closer to the camera before applying the position to avoid the jittering! Patches further away still jitter like crazy, but it doesn’t matter because they’re small and far away!

In the sourcecode you can see the position being modified in GeoPatch.cpp line 113 to subtract the "clipcentroid" which is the offset centre of the patch from the GeoSphere.

Then when we render it we apply the vector between the camera position and the clipcentroid on line 271, so everything is now rendered using camera relative positioning.

JohnJ is the genius who did most of this work before my time on the project. This is the commit/PR so you can see the subtle, elegant, changes that he made.

Andy

As an additional thought, If you're doing mesh deformation in the vertex shader based on a heightmap then you just need to keep the normals in the correct direction for that vertex, move then along that surface normal, then calculate the lighting based on a normal map passed in as a texture instead of from the geometry itself.

I haven't tried building or running your code base in a so I don't know what would be required to do so, but if you tell me how to set it up I can take a look and see if there's anything obvious that can be done?

Andy

Oh and if the video capture stuff is slowing the framerate down then look into uysing nvidia ShadowPlay since it should hardly impact on it at all.

I wish I could run nVidia's Shadowplay without having GFE installed - it annoys me!

As an additional thought, If you're doing mesh deformation in the vertex shader based on a heightmap then you just need to keep the normals in the correct direction for that vertex, move then along that surface normal, then calculate the lighting based on a normal map passed in as a texture instead of from the geometry itself.

 

I haven't tried building or running your code base in a so I don't know what would be required to do so, but if you tell me how to set it up I can take a look and see if there's anything obvious that can be done?

 

Andy

if you can spend some time on it without disrupting your tasks on Pioneer (and/or your social life  :D) it will be welcome of course. I'm a bit busy actually but I'll post technical details you need here ASAP

-Nev-

Only in case you're bored and you do not know what to do   😉

I haven't tried building or running your code base in a so I don't know what would be required to do so, but if you tell me how to set it up I can take a look and see if there's anything obvious that can be done?

 

Vertex deformation for terrain patche is done in this shader from this line to this line. Then here I add the height computed from Fbm functions to the vertex, and this final result is stored on vertex output here

Parameters to do this are provided to the shader here on CPU side.

To compile and deploy the vertex shader just right click on it under MSVC 2013 ide and choose 'Compile'.

Just be sure to use the official DX9SDK fxc compiler provided in my repo here rather than the one provided with MSVC2013, as this one produces weird results and behaviours.

Thanks for your help 🙂

Sorry Nevil, I'm not able to figure out quite what you're doing in there. Brain is too tired from work!  :slow:

Sorry Nevil, I'm not able to figure out quite what you're doing in there. Brain is too tired from work!  :slow:

No offence. Anyway this planet engine is probably the most complex piece of code I ever wrote in my whole life, including my IRL job.