A call for Garbage

[Ryder P. Moses]

Aw, hell, I linked to the wrong one anyway. My bad.

http://www.penguinbomb.com/donate/vs_models/meshes.rar

Try that. If not... I can break 'em into groups, but then there's no object whatsoever.

[chuck_starchaser]

Something weird's going on... I see the objects now in Notepad, but blender doesn't distinguish them; if I click on one, they all select...
I'm gonna try with mesher directly...

AHA! Meshe works with it! Hold on...

[chuck_starchaser]

SUCCESS!





Now, I don't think the multi-objectivity is really there, though; first blender didn't notice it; and mesher put out an xmesh that looks to me like a single object; AND it's still stopping the rendering; took me like 40 minutes to get that close to the thing to take the shots; I have to keep spiraling towards it while keeping it off the screen...

But we've definitely got a lot of progress, I'd say.

Anyone wanting to experience garbage personally, get this piece of junkinto your units folder, extract the junk folder. Inside the folder are the mesh and the textures; and there's a junk.csv, which has only one line, you need to add it to units.csv; and it has cephid17.system, which goes in the Sectors->Crucible; make sure you rename the old one just in case; I haven't updated my cvs in months.

[Ryder P. Moses]

It lives!

Did you try breaking it up in Blender? Any .obj file I output is going to be a little wonky one way or another, simply because MAX has to output them through a third-party exporter and they're a very different format than what MAX deals with natively. The farther down the changes are made in the conversion process the less likely they are to go wrong somewhere.


I really don't know why it'd be taking so long to render, though. Should just be a simple bare mesh and a UV map, right?

[chuck_starchaser]

I didn't break it in blender because if I do, I doubt it's gonna preserve the uv coords....... Hmmmm..... Maybe not. I'll try it tomorrow. Need some sleep now, it's past 2 am. I was editing the previous post; I put the file there with all the stuff needed to see it in-game. Sent you an email, also. Later.

[Ryder P. Moses]

Well, I'll see if I can do anything with it in the meantime.

And hey, cool, at least it renders the faces properly.

[klauss]

@chuck: mesher merges things with the same material, for performance's sake. You won't have objectivity. You don't want to, either. If you separate them, you would send them in multiple batches to the video card, and would mess up your entire scheme... you want them being one object. A vertex shader has to decide which to put in and which not to... but I can barely imagine how right now (...ehehe... barely, I did get an idea recently, but I'm not sure about its goodness...)

It didn't merge things before... that's my gift. If you don't like it, I can add an option for it not to do it. Maybe I'll add it even if you don't want me to... I guess someone sometime will, why wait?

[chuck_starchaser]

Ah, so you were talking about some rendering dilemma? When I said I'd write "most of the software" I meant all, up to the rendering part; I know nothing about how Ogre works; but AFAIK when you have a single mesh in the video card you can't tell a shader to display a subset of it, can you? So what I had in mind is that these would be separate meshes that sit in video ram permanently as models, but can be 'instanced' any time, anywhere, by a command. But if they have to sit in system memory instead, and be sent to the video ram upon instantiation, so be it; they are small anyways; would not take a whole heap of bandwidth to send one or two to the video card per render frame, as needed. So, I need to give each one a different material?

What's more important is that the texture be in video ram. I gues I could spawn the littlest piece of garbage in some place far away and leave it there, to force the texture to sit in the video card. (Put a pack of cigarettes at the center of the local star ... )

[klauss]

No. The very problem with modern GPUs is that they're too fast... faster than the CPU can handle. The CPU can't send commands as fast as required, and so in order to make the most of the GPU, you have to make the CPU send huge commands. That is... don't ever send a command to render 2 triangles... or 10... or 100... try to batch in the thousands.

So, by making your thing multiple objects to be instantiated, you force the CPU into multiple batches (at worst, one per garbage instance - at best, one per garbage type). Although one per garbage type sounds good... it actually isn't, given the number of such types. Rather, one sounds better. One... only one. How? having them all as a single object (after all, they use the same texture, so they require no state change between polygons), and making the shader hide triangles that shouldn't be rendered. How? hehe... just move them behind the camera

What I just can't get is to make a shader instance thousands of objects. Shader instancing can only take a little less than a hundred objects at a time... without rotation transforms. With them, less... 20 or so. Not good for this kind of thing, so how to fix that? That's a good question.

[chuck_starchaser]

Okay, here's another idea: I could do the instancing cpu-side; just generate the contents of a 1 km cube of space at a time, and send that to the card as a single object. How about it? Maybe we could even store the individual garbage models as command lists, so as to not have to send all of the geometry, maybe? Note: Randomizing the rotations of the garbage pieces is a must; but they don't have to spin or move; in fact, it would be much more realistic for them to be stationary, as any individual motions would tend to disperse in time by inter-collisions, and you wouldn't see them anyways. Same thing goes for "asteroids" by the way.

[Ryder P. Moses]

You want 'em to react individually if someone runs into them, though. That's a big problem with the asteroid fields I've seen, right now they act very plainly like a single object and that breaks suspension of disbelief pretty hard.

From a sheer aesthetic viewpoint, I feel like the trash should have a very slight movement of its own, purely random orbits spinning around at just barely perceptible speeds. Doesn't make all that much of a difference to me either way, though, so long as the trash bounces off your hull satisfactoriily when you smack headfirst into it.

[klauss]

Well... physics and graphics are totally unrelated, so no problem with that.

[Zeog]

From a sheer aesthetic viewpoint, I feel like the trash should have a very slight movement of its own, purely random orbits spinning around at just barely perceptible speeds. Doesn't make all that much of a difference to me either way, though, so long as the trash bounces off your hull satisfactoriily when you smack headfirst into it.

Make two or more cubes at the same spot, each with quite distant spaced junk parts and then slowly rotate the cubes in different direction. If the objects spaces are large enough they almost never collide and you won't notice. That should create a random moving junk feeling.

[chuck_starchaser]

Klauss. When you have a model that has LOD's, these are like multiple objects in one bfxm, and somehow the rendering part of the engine is managing to pick one of them and show it, while hiding the rest.

This is no different in nature; only in application. If the problem is mesher, maybe there's a way of persuading it (or hacking it) so as for it NOT to merge objects of the same material?

[Ryder P. Moses]

Do multiple LODs use the same texture, though? From a practical standpoint, I wouldn't think they'd be designed to.

[chuck_starchaser]

I've never done LOD's but I'm pretty sure they do use the same texture. I think you just unwrap them carefully so they match; but I could be wrong.
BTW, I started separating the obj file into many objects, but it's a lot of work. Somehow all the smoothing groups got mixed up. I had cubic boxes that were smooth shaded, and rounded things that weren't. Also found a couple of objects that had duplicate vertexes, and in many cases normals were flipped. So, I've only done a handful so far. And I'm not even sure this is the solution...

[Ryder P. Moses]

Not sure about in Vega Strike, but in most games lower LODs have significantly lower-res textures to go with them, since keeping the same big one for long-range LODs is pretty wasteful.

[chuck_starchaser]

Ah, okay; I didn't know. I did an FFE dashboard last night, for EliteStrike. Anyways, we'll just have to resolve this dilemma talking to klauss.
Ah, BTW, when I play Privateer Remake and Elite Strike, I get freezes of the display, so there's some problem with my machine, it seems.

[hellcatv]

more and more people are getting that

it's NVIDIA only and I don't know what causes it...

chuck: you're one of the very few people who's been with the project for a while who gets this error... can you please contact me on ICQ or AIM--we need to make a *very* minimal test case so I can send it to NVIDIA---they need to help us solve this one.

we gotta delete allunnecessary data and get it so it happens right after program launch and so it doesn't take more than 3 or 4 megs

[Ryder P. Moses]

Might have to do with one of the more recent drivers- Nvidia has been releasing some bad ones lately, I've had to roll back to an old one to get most of my stuff to run right.

[hellcatv]

that's one reason that Ogre will be nice---if OGL fails at least you can fall back to DX

[chuck_starchaser]

Update; it ONLY happens at FSAA 8x5. All other FSAA modes work, namely 2x, 2xQ and 4x. Tried again at 8x5 and it craps out again. I'm gonna try now at 4x with the garbage file. My driver version is 8.1.8.5

[chuck_starchaser]

The garbage looks gorgeous! I can even fly inbetween, no problems now.
Gimmi 2 minutes; I'll upload some screenshots.

Here:





Notice that only one side of each facet shows. The garbage bag to the right in the last images, one can only see the near side; I guess we have to do 2 passes, one with backface culling, one with front.

[klauss]

You can disable culling... in the xmesh file... adding the attribute cullface="false" to the material tag.

LODs: It's a good idea to use lesser textures (different), but has to be used with common sense... otherwise, you increase memory footprint far too much when multiple LODs are being used at a time. It definitely is possible to use different textures - and even materials - in each LOD.

I've experimented with a top LOD with 4k textures, a LOD with 2k, and one with 512 and simplified materials, and it does help a lot with far shots of stations and such, and in keeping texture memory free during battles far away from those stations, while keeping them very nice while up close. But it needs to be done with care.

This is no different in nature; only in application. If the problem is mesher, maybe there's a way of persuading it (or hacking it) so as for it NOT to merge objects of the same material?

Lots of differences in nature. LODs imply that other elements won't be sed, while in the case of garbage items, they may or may not be used. Also, LODs only "select a dataset" that represents the same object, not different ones. It's a wholly different concept. And needs a wholly different implementation as well. For instance, if you have to draw multiple LOD levels of the same object, you issue multiple batches. That's of no concern, actually, since you don't expect to have many - even if you have 10 LODs, you don't expect to be using all of them at once. And, if you did, 10 isn't that bad.
With garbage, though, it is entirely different. You expect to be required to draw multiple "LODs" - if a lod is a type of item - and you do care if you need multiple batches for that.

And there is a way. Remember? I offered to add such an option.

[chuck_starchaser]

What I meant by "same nature" is just the fact that there are distinct objects in a bfxm file, and they can be, and are distinguished in between.

Of course I know that in my case I'll have multiple, simultaneous instances.

All I was trying to say is that there IS a way not to mix all the objects into one; --that that is just a feature of mesher, which could be changed, and allow us to have separate objects in the mesh.

Now, if you're saying that for some reason we cannot produce more than one instance of an object, or more than one object simultaneously, I'd wonder why. When you switch LOD level, you're allocaing a new object and, by policy, deallocating another; but this is not a requirement of the hardware. It's just a policy for implementing LOD's. If you were to keep the old LOD around, the GPU wouldn't care, right?