September 09, 2010, 05:39:21 AM
News: As promised, here is another update of the editor with improvements and bug fixes
Pages: [1]
Print
Author Topic: New Release  (Read 678 times)
Jochen Stier
Administrator
Sr. Member
*****
Posts: 498


Founder/Programmer

jochen.stier@gmail.com
View Profile
« on: March 10, 2009, 09:39:44 PM »

I have uploaded a new version of the runtime client. This one is now using 2 Threads to compute the planet surface and the tesselation has improved a bit. You really need a 2-core processor for this one, but it should be worth a try.  It runs nicely on my Core Duo and 8800GT.
Logged
Tamarin
Full Member
***
Posts: 208


View Profile
« Reply #1 on: March 11, 2009, 08:03:05 PM »

Runs alright on my P4 3 GHz single core. There is a small amount of lag but not too bad. I'm happy to have the new (lightly used) 8800 GT.

I noticed that my processor continues to run "flat out" when I stop moving. Is this because the terrain algorithm continues to run? Is there a way to scale the speed at which random terrain is generated or stop it completely when I am standing still? I have to say that the terrain is unique and the star of the show.
« Last Edit: March 11, 2009, 08:18:12 PM by Tamarin » Logged
Jochen Stier
Administrator
Sr. Member
*****
Posts: 498


Founder/Programmer

jochen.stier@gmail.com
View Profile
« Reply #2 on: March 11, 2009, 10:23:46 PM »

Yeah, there is room for a performance improvement. At every frame, the terrain algorithm test which terrain patches need more detail and then schedules them to be split. Because this operation is so expensive, it happens in another thread. Actually it is two threads right now but it could be any number, depending on the number of processors. As soon as the patch has been split into four more detailed ones, the original patch is replaced.  Of course, four adjacent patches may also be merged if all of a sudden less detail is necessary, which usually happens when you turn or fly away. Long story short, even if you are completely motionless the terrain algorithm still tests if patches should be merged or split, which of course is not necessary. I also think its unnecessary to perform this test every frame. Especially if the threads are all busy splitting or merging patches. I will have a look at this soon ... I bet there is another performance improvement to be had here.
Logged
Pages: [1]
Print
Jump to: