getting the best display

[CoveredWagonz]

Hi all. new to pioneer. Im just a fan and tester. and to the developers: keep up the good workI want to get the most out of pioneer so I have a basic question about the graphics settingsare 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 specshttp://www.dell.com/us/dfb/p/latitude-d630/pdthanks if anyone can help

[ollobrain]

medium seems best

[Guest]

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.

[Guest]

OkIt is a normal glitch.I am expecting a very long Alpha.

[navi]

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

[fluffyfreak]

@naviIt'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.

[s2odan]

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 15:30-15:55 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)

[fluffyfreak]

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

[s2odan]

2.4... or is that children?

[fluffyfreak]

I pity your .4 of a child! I ask because I have access to the following:Pentium M, 1 Core @ 2GhzAMD, 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.

[s2odan]

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?

[fluffyfreak]

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

[fluffyfreak]

Ok, so how the hell do you give you a link to that branch?[url]https://github.com/fluffyfreak/pioneer/tree/NEVER_EVER_USE_THIS[/url] will that do?this is the commit 036d7dd2f99b337f46d4 id but I don't know how to give you a more useful link too it

[fluffyfreak]

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 loadWith 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.

[robn]

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.

[s2odan]

fluffyfreak wrote:
Ok, so how the hell do you give you a link to that branch?[url]https://github.com/fluffyfreak/pioneer/tree/NEVER_EVER_USE_THIS[/url] 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!

[s2odan]

@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]

[fluffyfreak]

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.

[robn]

s2odan wrote:

pioneer-msvc-9 2011-06-15 19-31-08-08.jpg

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.

[fluffyfreak]

@s20danWhat 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.