Want to try my demo?

Here’s how you make sure the original setting are restored.

//Firts you create a global DEVMODE variable:
DEVMODE devMode;

//then you save the curent mode
EnumDisplaySettings(NULL, ENUM_CURRENT_SETTINGS, &devMode);

//now restore when you’re all done
ChangeDisplaySettings(devMode, 0);

Ok, the ‘official’ quake console key under direct input is 0x29 aka DIK_GRAVE :wink:

That’s prolly the same one for the lparam too.

Man, I still use windows messaging :/. I need to get a DirectInput lib going on some time.

It runs on my W98+Celeron 366 + Riva 128 ZX 8mb with such results:
UV - 121
color - 86
Both - 82
none - 132

Hi,
I could not activate the console becuase my keyboard is not US or UK. By the default settings I had:

60
9

On the top left coner.

I have pentium III 733MHz with 512 Mbytes RAM & nvidia TNT2 Pro 32 Mb.

[This message has been edited by billy (edited 03-16-2001).]

[This message has been edited by billy (edited 03-16-2001).]

PIII 800 Coppermine 320mb RAM GeForce 2 MX 32mb

UV 542
Color 377
Both 325
None 650

Love the console You should make a program loop that times all four (or eight if you wanna take into account smooth vs. flat) modes and spits out the result into a text file… But I guess I’m just the lazy type, I actually had to go searching for one of them… whatcha callits… writing utensils

pIII 800 cm, geforce DDR

uv 1195
col 770
both 650
none 1400

How come colours are so slow? What format are you using for the colours? Float?
The UV perf is really good. What optimisation methods do you use? CVA? VAR?
Are you using a single directional hardware light?

Oh yeah, I tried loading some higher tess models. It works fine with a few k polys but when the count gets high the demo crashes. Any idea why? Have you already tried it with high-polygon models?

Madoc, I looked into the problem. It seems the vertex aligning algorithm is taking quite a bit of time to run through all similar vertices. The program never locked, it’s just taking forever to process :/. I guess we’ll have to stick to small models for now.

In the meantime, I’ll try to improve it.

I get “an invalid set of flags was passed in”

What vid card do you have Wulf? I’m assuming if it can’t get past the display change, you’re card couldn’t handle the demo anyway .

How come colours are so slow? What format are you using for the colours? Float?
The UV perf is really good. What optimisation methods do you use? CVA? VAR?
Are you using a single directional hardware light?

Whoa! I totally missed these question .

Colors are 4 floats…and your card prolly isn’t optomized for colors.

From what I understand about CVAs, they’re useless for this demo since there is only one pass for the skin, but it is used anyway.

I am using one directional light for the demo.

I don’t know what VAR is.

Here’s sample code:

glEnableClientState(GL_VERTEX_ARRAY);
glVertexPointer(3, GL_FLOAT, 0, Meshes->Vertices);

if(DrawingState & RM_NORMAL_ARRAY)
{
	glEnableClientState(GL_NORMAL_ARRAY);
	glNormalPointer(GL_FLOAT, 0, Meshes->Normals);
}
else
{
	glDisableClientState(GL_NORMAL_ARRAY);
}

if(DrawingState & RM_TEXTURE_COORD_ARRAY)
{
	glEnableClientState(GL_TEXTURE_COORD_ARRAY);
	glTexCoordPointer(2, GL_FLOAT, 0, UVcoords);
}
else
{
	glDisableClientState(GL_TEXTURE_COORD_ARRAY);
}

if(DrawingState & RM_COLOR_ARRAY)
{
	glEnableClientState(GL_COLOR_ARRAY);
	glColorPointer(4, GL_FLOAT, 0, Colors);
}	
else
{
	glDisableClientState(GL_COLOR_ARRAY);
}

if(glLockArraysEXT)
glLockArraysEXT(0, Meshes->nVertices);

//loop through triangles: loop not shown
glDrawElements(GL_TRIANGLES, 3, GL_UNSIGNED_INT, VertexIndices[i]);

if(glUnlockArraysEXT)
glUnlockArraysEXT();

No one has explained to me what CVAs and VARs are yet. I’ve asked but their description made no sence to me, they just said what it was, not what you use to accomplish them. Maybe you can explain it to me.

There is one trick I’m using to get the speed up. The GeForce doesn’t seem to care about it though. I remove as many repeated elements as I can. This process is really slow when the polys are high though.

[This message has been edited by WhatEver (edited 03-17-2001).]

I’ve got a voodoo 3 3000

I have a Voodoo3 3000 and it works fine.

Have you run GLsetup?

You ought to get better perf (at least on NVIDIA cards) by using unsigned bytes for your colour component. I wouldn’t say the geforce is unoptimised for vertex colours.
If you are using vertex colours and lighting I guess you’re using Color_Material. That would explain the performance hit.

VAR or NV_Vertex_Array_range allows you to allocate vertex mem in video or uncached AGP memory. It can really speed up vertex transfers.

Have you not tested the effect on performance of CVA?
If you really don’t know, CVA is supposed to store a processed form of vertices (mostly T&L OPs) when they are first used so that subsequent calls to DrawElements (or DrawArrays really) may reutilise them without reprocessing.

How do you arrange your triangles? (I think this is the clue to your demo’s performance)
What do you mean by remove repeated elements? Welding vertices and uv coords? Is that what takes so long?

Yeah, I guess you could call it welding. Every corner of every polygon tries to only share one: vertex, color, normal and uv.

I’m using color material alright.

The triangles aren’t aranged at all :/. I don’t know how to. They basicly keep the same order they were saved in the 3ds file.

So when I use: glLockArraysEXT(0, Meshes->nVertices);
I’m utilizing Compiled Vertex Arrays?

What does VAR stand for?

What does OPs stand for?

I’ve tested the performance of the Lock Arrays extention and they don’t make my models render any faster at all :/, even with a second pass executing between the Lock and Unlock ext.

I’m pretty sure I fixed the crashing problem. One of the variables were overflowing. Another bug was that if the uv coords were not saved in the 3ds file it would lock. I’ll upload the newer version later though.

GLsetup? Nope, it crashes during the install.

I’m surprised such a simple approach yelds such high performance. I wonder what order the triangles in the 3DS file are in. I suspect that on many cards it is not such an optimal approach.

ColorMaterial is certainly what slows the geforce down so much.

I explained what VAR is : Vertex_Array_Range, an nvidia extension.
OPs is simply short for operations.

On NVIDIA hardware only one vertex format is optimised for CVA: t2f_t2f_c4ub_v3f (quake3 format). Unless you are using this format it’s unlikely CVA will do anything but slow you down a tiny bit.
What card are you testing on?

VAR or NV_Vertex_Array_range

LOL, call me dense . The “or” made me not put two and two together, plus I’ve been really tired for the past few days.

Unless you are using this format it’s unlikely CVA will do anything but slow you down a tiny bit

Yep, by two frames :/.

I’m using a Geforce DDR, Geforce2 and a Voodoo3 3000.

I don’t have 3D Studio. I save my models from Rhino3D. Maybe they order their polys eficiently . Oh yeah, that mangalor(parts2) came with UView, so maybe that particular model was already optomized. I did load it into Rhino3D and explode the model though, so Rhino3D reconstructed the poly order.

I know what a CVA is now.

So what’s better; CVA or VAR? I can see VAR being better for NV cards, but CVA would be supported by more cards.

So, is there a better way to color sections of a model other than vertex colors using color material? I’m gonna update my lib to only support GL_UNSIGNED_BYTE sence you said it’s faster.