For all you know-it-alls

I'm doing some low-poly work and I've got some questions:

1. In a model, extremely elongated triangles are bad. But
if you had no other choice, would it be better to split it up
into multiple, less-stretched polygons, or would it be best
to leave them stretched?

2. I was thinking of texturing my model with a single
1024x1024 texture map. But I am throwing around the
idea of also having a (512x512) specular(or bump) map.
My question is: On the average videocard today, is there
any loss of speed at all for rendering textures with
multiple passes?

I'm assuming there isn't any penalty. Most videocards
have parallel texture pipelines for this sort of thing, right?

1. It depends upon if you are using vertice effects in any way. Lighting (especially specular) requires an even polygon distribution, mesh deformation effects like twisting your model on bullet impacts also look better when there are more vertices to work with.

2. Why go low poly if you are throwing a big texture at it? On most GPU's you will loose far more time rendering a detailed texture than you do rendering polygons.

I've found in B3D that secondary textures are very quick. However I had problems on my last card (GeForce 2 GTS) when I used a 3rd texture layer as the card natively only supported 2 layers (but 8 according to the drivers... hense problems.

There should be no speed hit for multi-texturing as long as your GFX card has enough texture units. The GeForce 2 does indeed only have 2 texture units so Blitz3D emulates when using more texture layers by duplicating meshes/textures which certainly does have a speed hit. GFX drivers often lie about their capabilities, it seems.

1. Because Blitz3D stuff is rendered as vertex-lit (DX7)it's good to chop the long stuff to get more even lighting... unless it's lightmapped with a full-bright texture of course (when it doesn't matter). Shader stuff is per-pixel and not per-vertex lighted so they don't have that problem.

2. With half-decent and half-modern 3D-card you can use several layers (at least 4) without any worries. Even GF3 had 4 pixel pipelines with two texture units per pipeline, and it's ancient crap these days when GF7's are out with 24 pixel pipelines...

http://en.wikipedia.org/wiki/GeForce_7_Series

Is this true? I would have thought that a large texture would
use more video memory, but not slow performance at all.

Banshee and Mustang: I will have no vertex lighting.
Textures will provide all light and shadow. It will look niiice.

Thanks, guys.


Here's another hypothetical situation for you guys:
Say you have two rooms A and B. You are standing in A.
Is it practical to load room B's textures and geometry on
the fly? (To keep video memory usage down)

For example: I'm in room A, room B does not exist in
memory at all. I walk into room B, it loads into video
memory and room A is erased. This way total memory
usage never gets too high.

This is the same type of thing that happens in BSP trees, right?

I realize that loading from the hardrive will be inherently slow.
But what if you could somehow keep all of your assets in Ram?

B3D does the memory juggle for you, there is no manual control over it aside from forcing textures into vram, but B3D does actually do a pretty good job.

Putting lighting onto the texture, or "texture burning" works with static objects and lights, I imagine from this then that you are referring too a level object and that the player is not carrying a lightsource? If we're talking about a level then the concept of low-poly varies wildly on opinion - what sort of numbers are we talking here?

I'll typically throw a few hundred thousand polys at my game levels with a couple of 512^2 textures and on a low end system it renders fine.


We should test this: Why not get an object with a 1024^2 texture and see how it works, then compare that to the same object but with the UV set to tile an excessive number of times?

That's assuming I'm doing this in B3d! I'm trying to get it
to work with OpenGl in BMax.

Alright, I've run many tests in BMax and the results are..... in your favour.

I set the test up to render a 512^2 quad and a 1024^2
quad under various conditions. These are the results:

Both at scale 1,1:
512 rendered 46% faster than 1024

512 blown up to scale 2,2 to match 1024:
512 rendered 31% faster.

1024 shrunk down to match 512:
512 rendered 38% faster


Oh well.

I'm still gonna use that 1024 texture though!

Alright, I've got another question you guys will probably know the answer to.

When you talk about storing in vertex buffers in B3D, is that
the same thing as OpenGl display lists?

I dont think I understand the question, sorry.

I don't own a copy of B3D, but I have heard talk of
"Storing information in vertex buffers". This sounded to
me alot like OGL display lists. If you do any OpenGl at all,
you might normally draw a triangle like this:

glbegin (gl_triangles)
    draw your points
glend

but, you can speed things up considerably by doing this first:

glNewList( MyTriangle, Gl_Compile)
    glbegin (gl_triangles)
      draw your points
    glend
glEndList

...and then by simply typing:

glCallList( MyTriangle)

The triangle is drawn like before, but at multiple times the
speed, because it's vertices are Compiled and stored in
the video memory.

Does that make sense?

My problem lies with the B3D'ers saying "Storing information in vertex buffers" part of the question. I'm not sure what that is referring too at all - i've no idea what a "vertex buffer" might be, let alone what information I would want to store in it other than x/y/z nx/ny/nz u/v.

[edit] Yeah it seems only BMaxers talk about them.
But I found a paper on Vertex Buffer objects, or "VBOs" at the
NVidia website.

It turns out it is just like a display list, only it's geared
towards usage over a network for multiplayer games. Interesting.

Anyway, here are some people talking about them

you cannot compare Blitz3D with OGL since Blitz is a DirectX 7 wrapper. Mark gave us a sandbox that is pretty idiotproof and nevertheless powerfull.

Geometry is organized this way:
A mesh may contains surfaces
a surfaces may contain a list of vertices
a surace may contain a list of triangles, containing 3 Vertex indexes each.
A vertex may have 2 texture UV coods, Alpha, VertexColor and Normals info.
A surface is painted by a brush. The brush may contain texture layers and has some properties.