rocks ROCK!

Post by **Raveen** » Sat Dec 16, 2006 5:46 pm

Yes Grimm, but models are harder to have as different in the game than textures. Alleg doesn't care what texture a model is using, it does care what shape a rock is.

Adaven · Post by **Adaven** » Sat Dec 16, 2006 9:06 pm

I think the work around for this would be Level of Detail scaling on the models. Supposedly Alleg already uses it for the MS models. Also spunky mentioned something about a slider you could pull up in game to change your detail settings, but I haven't found it yet.

If we can get this LoD stuff figured out and tested properly, we could potentially make a higher poly layer for the closest/highest detail level but enable low end users to bypass them via thier detail settings. That way those with the hardware can use the new models, and it will increase thier performance by not forcing them to use the high poly models at distnaces where you couldn't tell the difference without crushing the low-end user.

Also I don't think the download sizes are going to be as much of a problem as you think. The current model filesizes are all significantly small than the current texture filesizes, correct? The high res textures are 64x larger than the ms originals, I don't think these new models are going to have near 64 times the # of polygons.

Your_Persona · Post by **Your_Persona** » Sun Dec 17, 2006 12:14 am

Pedro wrote:QUOTE (Pedro @ Dec 15 2006, 08:18 PM) I thought everyone must use the same model in the same server.

Not exactally.

We must all use the same hit box.

Alleg could care less about the model you use, its the hit box that counts.

Thus you have problems with docking on some stations as the hitbox doesn't match the model correctly.

Adaven · Post by **Adaven** » Sun Dec 17, 2006 12:35 am

wait, so only the .cvh has to stay the same?

Terralthra · Post by **Terralthra** » Sun Dec 17, 2006 1:06 am

Adaven wrote:QUOTE (Adaven @ Dec 17 2006, 10:35 AM) wait, so only the .cvh has to stay the same?

It's not quite that simple, but basically, yes.

sgt_baker · Post by **sgt_baker** » Sun Dec 17, 2006 4:41 pm

Hi folks,

I agree that the low-poly models are a bit of a graphics boo boo at the moment. A coupla things relating to this issue:

A) Yes, alleg does use dynamic-LOD models for most MS ships, and perhaps other models too (I've not checked all of them /wink.gif" style="vertical-align:middle" emoid=";)" border="0" alt="wink.gif" /> ). IIRC we have levels of 64, 128 and 256 vertices for flyable ships. When Ksero and I were looking in detail at the graphics engine I made some 512 and 1024 (2x and 4x the highest detail level if it's not 256) vertex models of some of the giga ships, and boy, it made a world of difference, visually!

The way alleg reacts to higher poly models is something I've not done side-by-side tests on, but I suspect that there are a few reasons for this.

1. Alleg uses vertex buffers (fast) but at a resolution of one per model (not so fast). Putting all the models to be rendered into one big vertex buffer then sending that to the gfx card makes things faster, as only one memory copy operation is required between Ram -> Gfx card etc. (big horrible code-change)

2. (!not checked!) It could be that when people were testing high vertex models they didn't properly create the various LODs / Alleg is hard-coded to use LOD x at distance/size ratio y. Just bunging in more vertices or a new LOD is most likely going to break the performance gains of the LOD system. (minor code change for new LODs)

3. Many 3D packages are not weapons-grade or geared towards creating models for game-performance applications. Beware the duplicate vertex! (3D gfx is a deep and difficult subject /wink.gif" style="vertical-align:middle" emoid=";)" border="0" alt="wink.gif" /> ) Milkshape is positively HORRIBLE as a package, but the only one that naively supports alleg models atm. We've used blender and Maya, using Milkshape as a bloated conversion app. 'gu

4. Alleg, in theory shouldn't have problems with 2x and 4x LOD. If it does, it is something I suggest we make a concerted effort to track down, lest we be stuck with crappy models forever or have to recode the entire gfx engine. (If you've ever looked at it, you should be having a coronary right about now)

5. (edit) Afaik, alleg will run fastest when a mesh is a triangle strip.

6. A whole load of other performance related stuff...

C) I've said this time and time again: 'People have old machines' should NEVER be an excuse to avoid much needed development. If that were valid reasoning, we'd never have progressed beyond he abacus. After all, improvements can easily be coded to be optional.

Baker

mdvalley · Post by **mdvalley** » Sun Dec 17, 2006 5:36 pm

Allegiance uses something called Software Transform and Lighting. You see, figuring out where on the screen a vertex is supposed to be drawn on is quite mathematically intense. First you need to account for the camera FOV (multiplication/division), position (addition), and rotation (trigonometry). Add in the models scale (mult), position (add), and rotation (trig). Multiply by every vertex in the scene. And it has to be all re-done on every frame. Then you have to calculate how it’s lit. Figure out the light position, the vertex normal’s vector, and where the camera is relative to it all. Again, for every vertex on every frame.

That’s a lot of math. Even a modern CPU would have trouble keeping up with a complex scene. Newer video cards have their GPUs optimized to do this sort of thing, and they’re really quick about it.

Problem is, Allegiance doesn’t use the new techniques, and has the CPU do all the work. So higher poly models (or more models) puts ever-increasing strain on the CPU. That’s why probe art makes your framerate go to crap. It’s not your graphics hardware. That fancy new board is taking a vacation while your CPU is working its butt off.

Fixing it is a pretty large code change, unfortunately.

Oh, and while triangle strips are fastest, Alleg doesn’t use them. It uses individual triangles with indexed vertices.

sgt_baker · Post by **sgt_baker** » Sun Dec 17, 2006 6:41 pm

mdvalley wrote:QUOTE (mdvalley @ Dec 17 2006, 05:36 PM) Oh, and while triangle strips are fastest, Alleg doesn’t use them. It uses individual triangles with indexed vertices.

Yeah, that's what I meant /smile.gif" style="vertical-align:middle" emoid=":)" border="0" alt="smile.gif" /> I'm an OpenGL boy, so the DX teminology and calls are a little vauge on my end. Incidentally, you you know off-hand where in the code alleg is doing T&L or is it a DX flag that is set somewhere?

Edit: I've just looked up the DX software T&L system... isn't it just a matter of changing the HAL?

madpeople · Post by **madpeople** » Sun Dec 17, 2006 7:05 pm

i had thought about using the same hitbox for my models as the current ones and have it optional. (someone would need to convert the current hitbox into a format 3ds studio max understands so i can make my models fit in it.

one problem with this is, the current rocks are mostly round so they have a single convex CVH (convex hull) hit box...
"wtf, i did not crash into that rock!"

my rocks aren't really round, they have things like "craters" and dips in them which make them not convex, sure we could just say, dont fly too close to rocks, the cvh boxes aren't a good fit. it is an option, not really a good one, but still an option. (i may use multiple cvh boxes to make them a closer fit to my rocks)

i'm mostly making these models from spheres and using noise modifiers to deform them (i cant be bothered to place individual vertex's like i do with ships + i don't think it would work too well with more natural looking objects) then reducing vert counts, maybe once i decide which ones to use i will look closer and see if i can reduce some vert counts by hand.

should i make all the faces triangles, make sure there are no 4,5 corner polygons? would that help performance?

p.s. making the gfx engine better sounds cool, (but i'm not going to comment on it because someone said it was a big change)

sgt_baker · Post by **sgt_baker** » Sun Dec 17, 2006 7:22 pm

madpeople wrote:QUOTE (madpeople @ Dec 17 2006, 07:05 PM) i had thought about using the same hitbox for my models as the current ones and have it optional. (someone would need to convert the current hitbox into a format 3ds studio max understands so i can make my models fit in it.

should i make all the faces triangles, make sure there are no 4,5 corner polygons? would that help performance?

We were using a system along the lines of .mdl + .cvh -> Milkshape -> .3ds -> Edit model -> .3ds -> Milkshape -> .mdl + .cvh. Doing that resulted in all LODs and the hitbox appearing in separate layers of the .3ds file. (not that we used .3ds... we used .obj iirc).

Just a quick look at the source seems to suggest that alleg prefers triangles. As I say, I'm no DX expert, so I could be wrong.