Notifications
Clear all

getting the best display

Page 1 / 2

CoveredWagonz
(@coveredwagonz)
Crewman Registered
Joined: 13 years ago
Posts: 1
Topic starter  

Hi all. new to pioneer. Im just a fan and tester. and to the developers: keep up the good work

I want to get the most out of pioneer so I have a basic question about the graphics settings

are there ways to optimize my otherwise sub-par system in order to have pioneer run smoothly with high level of detail? the program usually lags when I set the texture above medium. this is bad news because well I dont want to see only medium planetary detail. 😥

Im running a Dell Latitude D630 laptop with of course the following specs

http://www.dell.com/us/dfb/p/latitude-d630/pd

thanks if anyone can help


Quote
ollobrain
(@ollobrain)
Lieutenant Registered
Joined: 13 years ago
Posts: 564
 

medium seems best


ReplyQuote
 Anonymous
Joined: 54 years ago
Posts: 0
 

The problem with medium in my computer is the graphical glitch when you are at a relatively far distance from the planet but having it in view. The surface turns "gridded" in an strange effect in the shaders.

it dissappears with the quality set to high but the performance is not ideal. It also dissappears with the shaders off, but without shaders the game loses the 70 per cent of the immersion and visual quality.

And with HDR on, the effect appears to be visually hidden under the "shinning"

Assuming the user is not affected by the the "shader glitch", I consider the Medium level of quality looks great and the performance improves a lot.

Greetings.


ReplyQuote
 Anonymous
Joined: 54 years ago
Posts: 0
 

Ok

It is a normal glitch.

I am expecting a very long Alpha.


ReplyQuote
navi
 navi
(@navi)
Crewman Registered
Joined: 13 years ago
Posts: 9
 

Unfortunate that the engine is not somewhat better. Could also look like this Techdemo.


ReplyQuote
fluffyfreak
(@fluffyfreak)
Captain Registered
Joined: 7 years ago
Posts: 1306
 

@navi

It's a tricky subject.

I don't know who has been writing the terrain generation and planet rendering (who?) but I think it's a balancing act. Do you extend the terrain generation to run on the GPU, which might limit your algorithms, and in the process lose support for lower-end cards/laptops? Or do you just work on creating the best CPU-centric system.

Also a lot of the videos you find are either taking that GPU approach or they're pre-computing their data.


ReplyQuote
s2odan
(@s2odan)
Captain Registered
Joined: 15 years ago
Posts: 1212
 
Quote:
(who?)

Terrain is Tom and myself, rendering is generally only Tom with the odd tweak from me or someone else. Pioneer is very CPU centric a mediocre GPU will be fine.

>3cores >3000Mhz is Pioneer's dream pc 🙂 For the GPU you just need one that will be able to keep up with the CPU and display all those triangles that are generated.

Quote:
Unfortunate that the engine is not somewhat better.

Define "better".

The terrain is pretty cool from that clip but I don't think its really a lot better than Pioneer's terrain on Very-Very-High, it is more detailed and refined though.

Compare the terrain from this clip by example, this is very-very high running in realtime although at times my CPU struggles to keep up. : Fast forward to 5:50 to skip to the nice terrain, Also skip to 1555 for a prime example of the CPU not keeping up(I had to pause the video and cheat 😉 to let the CPU catch up and load the detailed terrain)


ReplyQuote
fluffyfreak
(@fluffyfreak)
Captain Registered
Joined: 7 years ago
Posts: 1306
 

Out of curiosity, how many cpu cores do people have?


ReplyQuote
s2odan
(@s2odan)
Captain Registered
Joined: 15 years ago
Posts: 1212
 

2.4... or is that children? 😉


ReplyQuote
fluffyfreak
(@fluffyfreak)
Captain Registered
Joined: 7 years ago
Posts: 1306
 

I pity your .4 of a child!

I ask because I have access to the following:

Pentium M, 1 Core @ 2Ghz

AMD, 2 Cores @ 2.2Ghz (Old Desktop)

AMD, 2 Cores @ 2.4Ghz (Laptop)

Intel i7, 4 Cores (8 Threads) @ 2.66Ghz (shiny desktop)

And the actual terrain mesh generation code looks like a prime candidate for threading. I've been playing around with it and even with some _really_ awful threading code I've just thrown together I'm seeing a x2.94 speed up on my quad core.

This isn't something that I'm going to commit because... well it's awful code 😯 but I think it's probably just the tip of the iceberg.


ReplyQuote
s2odan
(@s2odan)
Captain Registered
Joined: 15 years ago
Posts: 1212
 
Quote:
This isn't something that I'm going to commit because... well it's awful code 😯 but I think it's probably just the tip of the iceberg.

Well I am interested all the same 🙂 Feel like commiting a branch for curious old me? 😉

The terrain does use threading already, but only to a point. It will run its own thread but not multiple threads... So if you have the terrain running on multiple threads, then I think that could be pretty cool 🙂

Your 2.94x increase in speed is compared to which of the pcs? Because if its compared to the single core one, I would say that its pretty normal even with the standard code.

Also how are you arriving at that figure? Is it based on FPS or based on loading times? I think its best to base it on the terrain loading time keeping detail settings the same for each set-up, because I would think that if everything else is kept equal (graphics carsd ect) then the i7 CPU should have lower framerates due to all the extra triangles it is throwing around from loading the terrain that much faster.

Ah and of course the most important question: How much CPU% usage was reported with the i7 while using your new changes?


ReplyQuote
fluffyfreak
(@fluffyfreak)
Captain Registered
Joined: 7 years ago
Posts: 1306
 

Ok, I'll see about sticking it on a "NEVER_EVER_USE_THIS!" or something 🙂 but it is just some horrific experimental hacking!

What I've done is create 4 threads that each wait on a semaphore, the terrain generation thread fills the data area for each of these and then signals the semaphore, each thread calls GenerateMesh on it's GeoPatch and then signals the completed semaphore. Hence why I call it a bit hacky, it was just an experiment to see if it would make much difference.

The performance results are on my i7 so it's likely that each thread is running on it's own hardware thread.

Dual and Single core machines will get much less benefit, in fact I think with the current implementation the Single core PC will actually perform worse!

I've added some profiling code recently and a simple windows only timer (all local but I'll push them with this branch), so all I do is find a reference point on a planet and save the game there with the terrain detail settings set to maximum. Then I load that up and harvest the results, close the game, change the #define to not use my threading code, run the game and load the save again, harvest those results and compare. Dead easy.

Also sitting here with a stopwatch and "guesstimating" when it's reached the same point shows it as being about 3 times faster ❗

We're not throwing around many triangles, most of our performance issues are CPU side, even on my main machine, likewise for my laptop I'd bet. The i7 has a nVidia 470GTX and it'll be a long while before we tax that 😀 They eventually reach the same level of detail being rendered regardless of the method used so rendering performance is always equal, only time taken to generate the terrain is less.

A proper analysis of optimisation methods should get us nearer to 4x speed up on machines like mine, 2x on dual core and perhaps just a slight benefit on single core boxes. However this isn't the right way to go about it, it's just a cheap win to test with.

Andy


ReplyQuote
fluffyfreak
(@fluffyfreak)
Captain Registered
Joined: 7 years ago
Posts: 1306
 

Ok, so how the hell do you give you a link to that branch?

https://github.com/fluffyfreak/pioneer/tree/NEVER_EVER_USE_THIS will that do?

this is the commit 036d7dd2f99b337f46d4 id but I don't know how to give you a more useful link too it 😳


ReplyQuote
fluffyfreak
(@fluffyfreak)
Captain Registered
Joined: 7 years ago
Posts: 1306
 
Quote:
Ah and of course the most important question: How much CPU% usage was reported with the i7 while using your new changes?

Oops, missed this question, rough answers are:

    [*:1p6ykb77]With my threading between 45% to 59% CPU load

    [*:1p6ykb77]With single thread between 27% to 36% CPU load

With a base load of ~20%.

So as you can see, there's LOTs of headroom that we could be using. I don't like to wildly speculate as to what we could achieve, but I do think that there's room for improvement in there.


ReplyQuote
robn
 robn
(@robn)
Captain Registered
Joined: 13 years ago
Posts: 1035
 

This is good stuff. You're right that it likely won't get used in its current form, I'd definitely like to see it integrated in some fashion.

I think what I'd most like is some kind of probe to find out how many cores are available and their characteristics and then configure the number/type of threads appropriately. If we add more threaded stuff (eg issue #23) then we'd want to allocate threads to things based on user settings. Maybe asking for higher-quality terrain gets you more threads.

Its definitely a challenge, but not at all impossible - thread pools and allocations are the bread-and-butter of network server development; there's plenty of work and experience out there to steal from.


ReplyQuote
s2odan
(@s2odan)
Captain Registered
Joined: 15 years ago
Posts: 1212
 
fluffyfreak wrote:
Ok, so how the hell do you give you a link to that branch?

https://github.com/fluffyfreak/pioneer/tree/NEVER_EVER_USE_THIS will that do?

this is the commit 036d7dd2f99b337f46d4 id but I don't know how to give you a more useful link too it 😳

thanks dude 🙂

Quote:
Oops, missed this question, rough answers are:

* With my threading between 45% to 59% CPU load

* With single thread between 27% to 36% CPU load

*EVIL LAUGH* MWUUHAHAH , 😉 Seriously though. this is awesome. Although I spent most of yesterday actually reducing detail so that very-very-high mode would run very acceptably on my 2.4 Q6600 box, but that doesn't matter... I suppose a problem will be in the difference now between the noise used for low quality and noise used for high quality.. V-V-High mode basically just increases the range at which details are loaded, thats all... But what we'll need is actually seperate noise patterns for multi-core/very-very-high mode, so we can really tax the CPU...

Hmm... Ok I will keep in mind that you have a beastly i7 and within the next couple of days I will make a terrain patch to truly test it 😉 (Obviously when combined with your threading code)

This is also cool because for months and months I have had some particular ideas with regards to the terrains and colours, but I didn't want to raise CPU usage at the time as it was already getting slow.

Small example of the ideas: Ok, Mountains and other features at the moment are just plonked down without any other regard for anything, they are also coloured based solely on height, and on occasion there is some variation in colour due to equatorial regions seperated by noise patterns (This is new though and not all terrains have it).

But what if we practically did away with height based scaling, and instead scale colours by regional areas... What that would mean is that the big mountain range your approaching would actually have a different colour and texture to the other surrounding land, even though the height might be the same.

Same goes for craters and volcanoes, you might want the crater to have a different colour tot eh rest of the land, you can do it by applying the fractals through the colours in this way.

Lakes, fake rivers ect ect... All done in the same way.

Anyway, awesome work! 🙂


ReplyQuote
s2odan
(@s2odan)
Captain Registered
Joined: 15 years ago
Posts: 1212
 

@FluffyFreak, I made a branch using your threading branch as base, it has increased detail for Earth using more octaves and lots of extra noise and a few more fractal definitions. 🙂 This will be cool with your i7, I get up to 90% usage with my quad, and you notice the terrain generation eating into the main thread, so those extra threads of the i7 will be great in this case 🙂

https://github.com/s20dan/pioneer/commits/threading

[attachment=792:pioneer-msvc-9 2011-06-15 19-31-08-08.jpg]


ReplyQuote
fluffyfreak
(@fluffyfreak)
Captain Registered
Joined: 7 years ago
Posts: 1306
 

Ah I see you've also had to disable the DXTn compression test! 😆

After thinking about it, the fact that it burst up to 59% on mine is amazing, as the only way to hit 100% would be to use all 8 threads but under this thread testing the most pioneer can run is 6, i.e: main, sound, + 4 GeoPatch threads. The usual LODUpdate thread is suspended when the GeoPatch threads are running. The best it could achieve is 75% utilisation for which it would need to max out all threads... but the sound and main thread don't actually take that much time.

Been trying to imagine a better scheme.

This one would require a bit of refactoring to do however you could rewrite the LODUpdate function to work in stages for splitting:

Stage1 :

Go through the quadtree and find ALL of the kids that need generating, add them into one big list (or when adding, spread them across N thread local lists).

Stage2 :

Get all of the GenerateMesh threads to run through every child in the list (/per-thread list) generating the mesh.

Stage3 :

Fix-up, do all of the post-mesh generation stuff here, i.e: create edge normals, update vbo etc.

I think that might get better thread utilisation but it might be a lot of work.


ReplyQuote
robn
 robn
(@robn)
Captain Registered
Joined: 13 years ago
Posts: 1035
 
s2odan wrote:
[attachment=0]pioneer-msvc-9 2011-06-15 19-31-08-08.jpg[/attachment]

Holy crap. When I first saw this I thought you were being a smartarse and you'd taken and actual picture and overlaid the hud on it. That's amazing.


ReplyQuote
fluffyfreak
(@fluffyfreak)
Captain Registered
Joined: 7 years ago
Posts: 1306
 

@s20dan

What do you think about doing colourisation/texturing in the shaders?

A good half of the terrain generation time is getting the colour for each vertex as it has to go through the noise system again.

Instant win performance wise.


ReplyQuote
s2odan
(@s2odan)
Captain Registered
Joined: 15 years ago
Posts: 1212
 
Quote:
Holy crap. When I first saw this I thought you were being a smartarse and you'd taken and actual picture and overlaid the hud on it. That's amazing.

hehe, 😉

R.E. Shaders, If you think you can do it, then go for it 🙂 But I have nfi how you would convert the fractal stuff into a form for glsl but I presume it could eventually lead to some nifty things like fractal clouds 😉

But someone on IRC mentioned how older cards would have trouble with that, but theres nothing to say it can't be optional.


ReplyQuote
s2odan
(@s2odan)
Captain Registered
Joined: 15 years ago
Posts: 1212
 

Here's a video of the terrain, my CPU barely made it back from this one 😉


ReplyQuote
Coolhand
(@coolhand)
Master Chief Registered
Joined: 13 years ago
Posts: 112
 
fluffyfreak wrote:
@s20dan

What do you think about doing colourisation/texturing in the shaders?

A good half of the terrain generation time is getting the colour for each vertex as it has to go through the noise system again.

Instant win performance wise.

i have mentioned this before, and would be willing to provide a good set of textures for this, for different surfaces, i have no idea really why the coding devs are so set against this idea, or at least are not even willing to discuss it. I'm sure you could get better looking terrain for the same amount of processing time, or a win-win on both fronts.

to me, honestly the planets are ok, but they don't look particularly realistic much of the time, there's a lot of room for improvement and a lot of that could be done by craftily incorporating bitmaps.

...guess i'm just wasting my time even mentioning it though.


ReplyQuote
robn
 robn
(@robn)
Captain Registered
Joined: 13 years ago
Posts: 1035
 
Coolhand wrote:
i have mentioned this before, and would be willing to provide a good set of textures for this, for different surfaces, i have no idea really why the coding devs are so set against this idea, or at least are not even willing to discuss it. I'm sure you could get better looking terrain for the same amount of processing time, or a win-win on both fronts.

guess i'm just wasting my time even mentioning it though.

Its the same story - there's a limited number of devs, each with their own set of interests and amount of time they're willing to contribute to the project. Using textures for terrains may objectively be the right way to do things but if nobody is interested in writing the code or feel that their time is better spent elsewhere then there's not much more to be said.

Personally I don't know enough about terrain stuff to be able to comment on the "correct" approach. If s20dan & fluffyfreak (& others) want to hack on fractal terrains, that's their choice.

This is exactly the reason we encourage ideas to be added to the issue tracker. Right now there may be nobody interested in it, but perhaps one day there will be. Putting the idea in the issue tracker ensures that it is not forgotten.


ReplyQuote
durandal
(@durandal)
Petty Officer Registered
Joined: 13 years ago
Posts: 44
 

Are you plan to use static textures for every planet in galaxy?


ReplyQuote
Page 1 / 2