Optimizing The Renderer

[crusadingknight]

Just out of curiosity, why do you use --binary?

[DarkWarriorBOW]

@Wytter : Still no good. same problem You could be right, altho the patch I am using is GNU compliant and should be able to read it.

In fact, it DID read it correctly first time and applied without complaining. Odd.. Time to have the linux rig a go at it.

 

@crusadingknight : Because in *nix, there is no difference between binary or textfile, and therefore, i treat all files that come from such a system as a binary. It is the only way that for example patch will read it as it should. (no cr/lf at the end of each line)

 

info on what kind of patch i am using :

patch 2.5.4

Copyright 1984-1988 Larry Wall

Copyright 1989-1999 Free Software Foundation, Inc.

 

This program comes with NO WARRANTY, to the extent permitted by law.

You may redistribute copies of this program

under the terms of the GNU General Public License.

For more information about these matters, see the file named COPYING.

 

written by Larry Wall and Paul Eggert

 

--- fyi, its the same that comes with virtually any linux flavor

 

update :

 

trying it on my devrig :

 

 

Sorry, i give up LOL.

Edited May 7, 2005 by DarkWarriorBOW

[espenfjo]

Thats weird, it applies fine here

[DarkWarriorBOW]

ok....

 

Well, i deleted the CVS mastertree, and redownloaded it, so it can't get any cleaner than that..

Tried to apply it again.. same results.

Copied the tree to my devrig and tried to patch.. again same results..

 

<_< it's a conspiracy.....

[LabRat]

I have applied this to clean CVS 3 times so far today, no problems at all.

 

I am patching using Cygwin using the following method:

save the patch file to the source directory

start cygwin and go to the source directory

$ patch -i vbo.diff

simple as that

 

you may wish to consider "patch --dry-run -i vbo.diff" until you figure what the problem you are having is..

[DarkWarriorBOW]

Alas I lack time to dig into it. Got some other projects running as well.

It's strange tho, as it went haywire with the last 2 updates on that patch..

Maybe if im in the mood i'll patch it in by hand. Timeconsuming, but always works.

Sorry that I can't help debug it.

[espenfjo]

  ok....

 

Well, i deleted the CVS mastertree, and redownloaded it, so it can't get any cleaner than that..

Tried to apply it again.. same results.

Copied the tree to my devrig and tried to patch.. again same results..

 

<_< it's a conspiracy.....

160041[/snapback]

 

 

You have tried to redownload the patch?

[DarkWarriorBOW]

lol. i lost count on how many times i downloaded that thing.

 

hmmm... maybe windows fuX0rz it up..

[Wytter]

Well, you should be able to download it as vbo.diff without saving it with the .txt extension. Are you copying it into a text editor? Because in that case that's where the problem is.

 

I'm using patch v/2.5.9

 

Oh, and I uploaded a new version.

Edited May 8, 2005 by Wytter

[DarkWarriorBOW]

LOL

 

Well, what you just said gave me an idea. yes i downloaded it straight to my hd all the time, and not copy and paste it into notepad as i assumed that would fubar it.

So, I decided to go against the rules and do exactly that.

 

And guess what..

 

patches in without a problem, even on my expirimental sources.

 

How nice how windows manages to fux0r downloading a simple text file up and leaving you digging out a problem for hours. Do more in less time you said ?

[Wytter]

Good, now tell me - is it crashing for you quickly still?

[DarkWarriorBOW]

Ok, well, here it is Solid as a rock up to now.

 

 

BUT

 

It keeps giving me weird spikes on Isla Prima..

Altho it looks cool, i hardly believe its intended to be this way :

 

 

Any ideas ?

 

p.s.

 

One thing i need to add. up to now this use of VBO also rids me of that insanely annoying texture flashing. I will try it on the NVidia chipset asap and see what happens there *crosses fingers*

 

EDIT : no such luck on the NVidia chipset

Edited May 8, 2005 by DarkWarriorBOW

[Entropy]

IMO, the best way to get performance&quality is to drop the "object" as the main entity in a map and switch to space partitioning entirely. That is, don't store the map as a list of objects, but compile the map as a list of polygons organised in BSP or octree, with each leaf being a VBO with its materials sorted. Traverse the tree, and if a leaf is visible, just render the VBO. You can't get any faster than that.

159952[/snapback]

 

Actually, Sadez made it so that we are only checkign for the objects nearby (in the current sector), so we don't have to go through 10K objects each frame (only about 200 or so).

 

Anyway, Wytter is teh r0x!

[Wytter]

DWB - it IS actually supposed to look like that; fortunately .

 

Well, after a bit more of testing I think it'd be safe to commit it then

[DarkWarriorBOW]

LOL.. oh..

Well eehmm.. it didnt show this in the original CVS for me.

Good that this vbo thing also fixes that

[Wytter]

Just tried it on a windows computer with an FX 5200. It's clearly getting GPU limited now, since the CPU usage is ~33-50% when it's rendering all that it can. That's the explanation behind the framerate jumps. We need to find ways to improve the framerate on the GPU, and perhaps put a bit more load on the CPU.

[mikeman]

You might get better CPU-GPU balance with simply rearranging the code. For example:

 

if(SphereInFrustum(objects_list[l]->x_pos,objects_list[l]->y_pos,
              objects_list[l]->z_pos,radius))
         {
                         	draw_3d_object(objects_list[l]);
         	if (read_mouse_now && mouse_in_sphere(objects_list[l]->x_pos, objects_list[l]->y_pos, objects_list[l]->z_pos, radius))
           anything_under_the_mouse(l,UNDER_MOUSE_3D_OBJ);
         }

 

This is a part of a loop from the display_3d_non_ground_objects(), but the same thing happens all over the program. SphereInFrustum() uses CPU, draw_3d_object() uses mainly GPU, and the calls are mixed together. That means that for every object the GPU has to wait for CPU to complete SphereInFrustum() before it can put in the rendering pipeline the command to render a new VBO. If the calls to CPU and the calls to GPU(OpenGL code) are grouped together and not mixed up, then the card can render the models and the CPU to do its calculations at the same time.

Edited May 8, 2005 by mikeman

[Lachesis]

Would using different threads for rendering and other calculations help with this as well, mikeman? For instance, one thread chooses and prepares the objects to be rendered (using mainly CPU) and another one actually draws them (using mainly GPU)? Big parts of the scene don't change, so the overhead of saving the rendering tasks in a data structure might be balanced by some calculation savings.

[Wytter]

Yes Mikeman, I think that this is happening as well and it could explain the massive fluctation in the rendering speed (from 20-50 fps over 2 seconds is not uncommon).

 

Perhaps we could even make an index of objects that are the same, then render all similiar objects through 1 call to OpenGL? Is that possible in OpenGL? If so, is it also possible for objects with different rotations?

 

Furthermore I think that we should make sure that only objects in the front of the camera are rendered. Currently it's only based on the distance, but it might improve performance (by simply telling the renderer to render less objects) to use an AABB tree to determine which objects we should render.

Edited May 9, 2005 by Wytter

[Wytter]

Making a list of objects to render every time the scenery changes (when rotating, walking, tilting) should be easy to do as well. That way we don't have to use the CPU as much as we do today in the rendering phase, and it should increase performance somewhat.

 

When the list is created, all rendering could be done with something like:

 

for(i=0;i<no_near_3d_objects;i++) draw_3d_object(near_3d_objects);

Edited May 9, 2005 by Wytter

[mikeman]

Also, the shadowmapping seems to slow down the game significantly. From what I've seen, the light proj frustum seems to have size of 40x40, while the camera frustum has size 10x10(in full zoom-out). That way you render a lot of objects when you don't need to, and also the portion of the shadowmap you're actually using is very small, thus the very low quality shadows. The light frustum must be wide enough(left,right,top,bottom planes) just to cover the view frustum, oriented towards the light direction and the near plane positioned at the maximum height of objects.

[Wytter]

Thanks, we were wondering what was causing that problem. Can you try fixing it? I'm not near a development computer atm, and will only get to one on saturday.

[mikeman]

Sorry, I misunderstood the code: the view frustum have the z planes at (-40,40), so when the camera(or the light direction) is rotated around the x axis, the light frustum does "cover" a big area. I tried narrowing down the light frustum(assuming z planes at lower values) and changing it dynamically based on the zoom factor, but sometimes the shadows just pop in/out. The current code is more or less correct, so that's not the reason why shadows are low-res. It's just the way it is. The obly robust solution it seems is to use multiple shadow maps(3 or 4 should be enough), but I'm busy with Cal3D right now, so I can't do that. Maybe when I'm done I'll give it a shot.

Edited May 10, 2005 by mikeman

[Mr_Maniac]

I've tried out your Patch and it works very well...

 

My sys:

 

Athlon Thunderbird 1.333 MHz

512 MB RAM (Non-DDR)

GeForce 3 - 64 MB VDDR-RAM

Gentoo-Linux with Kernel 2.6.11.8

 

Without Patch: 20~120 FPS

With Patch: 30~200 FPS

 

No Crashes...

[Wytter]

Good to hear

 

I'm working on creating lists of things to display so we won't mix preprocessing with rendering. This should increase performance as well.

 

A thing that I really hate is that our reflections are sooo slow. I've tested and found that the heavy slowdown is caused by using glClipPlane() - clearly there has to be a better way? It seems to be using the CPU heavily, which is of course very inefficient.

Edited May 14, 2005 by Wytter