A call for Garbage

[chuck_starchaser]

Not sure how you feel about this, Ryder...

I'm debating in my mind if each main texture should be 512 x 512 or 1k x 1k.
At 512 by 512, the 9 paper textures take up about 60% of the space. On the other hand, the rest of the stuff is more detailed geometry-wise, and therefore doesn't need as much detail texture-wise... And it would be nice if the 4 main textures could be tiled into one 1k by 1k. (I've experienced a slowdown when using a 2k by 2k texture, with a ship I was working on, and the idea for the garbage is to step lightly on the video card, so as to incur the least overhead). Leave it up to you.

EDIT: Come to think of it, each main texture could be 1k x 512 also... so 4 of them would come to 2k x 1k...

[Ryder P. Moses]

512x512 for each is probably fine. It'd be a big graphical improvement over 384x384 to the point where you could probably even read some of the documents if you really wanted to, and the file space and processing time for a 1k would probably be better spent elsewhere.


Oh, yeah, and the UV coords came through, right? Wanted to make sure of that before I did anything I can't reverse.

[Ryder P. Moses]

Hm; I think I buggered up somewhere in setting up the grid. Oh well, see how this works:

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


Also, I'm thinking that Smacky the Needle needs to become the VS mascot. He's just so cute.

[chuck_starchaser]

No, that's not what I meant...
The sub-textures *have* to be power of two sizes, so, if anything, we'd have to double the size of them, which IMO is too much. What I meant is the main texture size, in which the 3x3 text textures would be. I think 1k x 512 should work well for the main texture. Like this:



That's one of the four main textures, where the grey area is for the other objects' textures.
Then the four main textures put together into a 2k by 1k.

Then, for the uv mapping, all objects would be uv-mapped to just the first of the four main textures, and similarly, all the square craps would be mapped to the first of the 9 paper subtextures. I can then use offsets that I add at random to pick alternative main textures, and alternative sub-textures, at run-time (just pass those offsets to the shader).

[Ryder P. Moses]

Okay, you lost me somewhere, but I get it now. Yeah, sure, that'd work. I'm not so sure that each of the subtextures is exactly the same size now, though, but that's easy enough to fix while rearranging the stuff.

[Ryder P. Moses]

You know, it occurs to me that we need a lot more ISO pamphlets in the space-garbage. Maybe I'll make another texture, if I can find some more. Anyone care to take a crack at designing some miscellaneous VS propaganda?

[chuck_starchaser]

Hmmm... What about the VS promo screens? Bit of an Easter egg...

So this is what the full texture would look like, except double the size; I reduced it so it fits in the forum webpage



But everything just uv-mapped to the top-left quarter only.

How about book-cover 'Das Kapital -- K Marx"; black leather, gold lettering (yellow specular).

EDIT:

Actually, we could have faction-specific garbage. I was originally planning to have 2 garbage levels: Generic garbage (the stuff we're working on), which sits in the video card permanently; and base-type specific garbage, like vegetables, egg cartons and rats for agricultural bases, and nuts, bolts , tools and machinery parts for industrial bases, etceteras.
But we could have a third file we load that varies with faction. So we could have items of Rlaan food and furniture; another file with Aera food, clothing and furniture; and near Iso bases we could have a lot of communist propaganda pamphlets, books, posters.

EDIT:

Alright, to get the software started, here's how we generate random offsets for non-paper objects and for paper objects:

Code: Select all

struct uv_offset
{
    float Du, Dv;
};
inline void random_main_texture( uv_offset & uv )
{
    int i = int( floor( 4.0f * rand() ) ); //assuming rand() returns 0.0 to 0.999...
    uv.Du = 0.5f * float( i & 1 );
    uv.DV = 0.5f * float( i >> 1 );
}
inline void random_paper_texture( uv_offset & uv );
{
    const float u_subtext_sz = 128.0f / 2048.0f; //subtext size/texture width
    const float v_subtext_sz = 128.0f / 1024.0f; //subtext size/texture hight
    random_main_texture( uv );
    int i = int( floor( 9.0f * rand() ) ); 
    uv.Du += u_subtext_sz * float( i / 3 );
    uv.Dv += v_subtext_sz * float( i % 3 );
}

[Ryder P. Moses]

...You lost me again. I thought we were putting all the images in one texture; why're we creating four different ones now?


Man, the forum's eating posts now.

[chuck_starchaser]

The big texture is divided into four main textures. Each main texture is an alternative set for all the objects. But you don't need to worry about it. Let's pretend it's just one texture. Later you do another, alternative texture; later another, later another. Eventually, I will put all four together into one big one, simply because it's more efficient for the videocard to deal with all 4 in 1. (Otherwise, each time it needs to render an object with a different texture from the previous one it would have to reinitialize a texture unit. Long story.)

So, you can do each of the four separately. (Of course, they all must use the same uv mapping.)

Afterwards, I'll put all 4 textures into one, and I'll go through the .obj file and divide all uv coords by 2, manually, using the windows calculator.

Then, at run-time, I will generate texture offsets as I spawn each object, that will select one of the four main sub-textures. These offsets will be picked at random and will be one of four:
0.0,0.0
0.0,0.5
0.5,0.0
0.5,0.5
That's what the first routine in my previous post does.
I'll pass these two numbers to the vertex shader, which will then add them to the uv coords of each vertex for the object on the fly.

Same story for the paper subtextures, except here the random offsets are of 9 possible random combinations, and the numbers are smaller.

But you don't need to worry about this. Just do one texture at a time; I'll take care of the rest. So, say, grab this one...



There's room for 7 more 128 x 128 textures on the left side; and the right sid you could subdivide into sixty-four 128 x 64 rectangular subtextures.
That would give us a total of 64+16=80 sub-textures. Hmm... You'll need to make some 64x64, I guess, to have enough subtextures.

[Ryder P. Moses]

Oh, I see, so the rest of the space is for the fans and hats and things, yes?

[chuck_starchaser]

Exactly.
But don't forget, all the papers meshes should uv map to *one* of the 9 subtextures: the first one (top left). That way I can select one from the nine at random by adding 256, 128 or 0 to u and v.

[chuck_starchaser]

Here's a template you can use as background for the uv-mapping:



that's 9 128x128 for paper textures, plus 3 more for whatever, and 80 64x64 texture slots.

[Ryder P. Moses]

It was a dark and stormy night!
There were no stars in sight!
It was a simple flash of light
That brought my baby to life!

Piece-meal was what she was!
Close-up you could hear the buzz!
No one in this whole world
Will ever take my Frankenstein!

(FRANKENSTEIN GIRL)
She was made to love me!
(FRANKENSTEIN GIRL)
She was built to hug me!
(FRANKENSTEIN GIRL)
She won't ever leave me oooout!
(FRANKENSTEIN GIRL)
She loves to please me!

[chuck_starchaser]

Some people believe in the Anti-Christ.
How come there's no Anti-Frankenstein?

This whole garbage thing is like an Anti-Frankenstein:

(Actually, Frankenstein was the name of the professor that made the monster, not the name of the monster, but anyhow...)

Frankenstein is putting together an "individual" from pieces.

This garbage thing, to the contrary, creates the illusion of a multiplicity of unrelated crap, but it is based on one mesh, one texture, one code, one shader.

Well, I guess the horror equivalent would be the borg... They appear to be many but are just one, kinda thing.

Okay, no, the borg are still a living thing. How about a horror story where there's a fake multiplicity of droids. You think you own your droid but your droid is actually a spy that logs everything you do for the benefit of an ai based conspiracy...

Well, that's the case presently, you think you "own" a computer, but the computer is the means for corporations to own you, through spyware. So, too late to make a horror story like that; we're living it.

How about a computer that can model the entire planet, and make forecasts, not accurate but statistically correct in the bulk, like weather forecasting, like a bit of chaos theory and Asimov's psychohistory, and can steer the course of future history by making slight changes no one would suspect would have enormous consequences in the long term, and its agents are robots that people buy for household duties.... When their owners are sleeping or at work, they get out through a window or chimney and do things like stealing a letter from a mail box, or pulling out a wire from a car so that someone is late for work that day and misses a meeting so that his or her opinion is not heard and a descision is made which affects the future of the company which causes that company to never get a big government contract, which prevents an unrecognized genius in that company from being involved in the development of a new weapon that...

[CoD]

I think you're talking about somthing like The Matrix... aren't you?

BTW: I'm working on mule interiors but if you need me let me know.

I'm thinking about metal textures with holes, scratches and beam burns...

[chuck_starchaser]

Ryder, can you post the uv stencil if/when you have it? That way maybe CoD could do one of the four alternative main textures.
Thanks.

[Ryder P. Moses]

Okay, but I'm warning you, it ain't pretty...

[chuck_starchaser]

Actually, I find it pretty, but there's a practical problem of the subobject maps crossing grid lines. This causes the individual objects' textures to mix with one another when the texture is reduced by powers of two to generate the mip maps. So objects would change colors as you approach them. First the whole object, then towards the edges. But anyhow, we could just disable mip mapping for now, just use point-sampling and to hell with it. It's supposed to be garbage, anyhow and I can see it would be difficult to fit long rectangular things into squares...

@CoD: I guess you'll need one of Ryder's textures before you know what's what there...

[Ryder P. Moses]

The first texture was in that .rar file I posted. Additional ones are proving difficult at the moment, due to file lossage and troubles in recreating the original geometry mapping. I might have to start over again anyway at this rate.

[chuck_starchaser]

IFFFFF you do start again... and IFFFFFFF it's not too hard to do, using this template...



... and keeping the mapping of all the objects within individual squares would allow mip-mapping to work without producing artifacts.

And remember, only the objects that aren't pieces of paper need to be mapped onto the small square slots. The rectangular, paper objects would all map to the same region in the texture: The top left corner square 128x128.

The little squares may seem small, but, say, for instance, the big bag: It doesn't need much detail, and the front and back sides could use the same texture coords. Same thing with a lot of the crap, like those #-looking things made of inter-crossing rectangles, all the rectangles for one object could share the same texture.

[chuck_starchaser]

Example:



EDIT:

Come to think of it, keeping each object to its own square should make texturing easier; --all you have to do is assign a material to each square, though it may be more difficult to uv-map. I donno cause I've never tried uv-mapping yet...

[Ryder P. Moses]

Ah fixed ick.

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


Mind that you wanna keep the textures kinda even, with no distinct features stretching over more than one face. Some I just had to flat-map to get 'em to occupy any worthwhile amount of space in the boxes, so anything that goes over an edge will look clipped and ugly.

I'll bake some texes in in a bit. Right now I'm kinda burned out on that particular model.

And what's up with the url code suddenly up and dying?

[chuck_starchaser]

Hmm... the .obj again crashes mesher...

Mind that you wanna keep the textures kinda even, with no distinct features stretching over more than one face. Some I just had to flat-map to get 'em to occupy any worthwhile amount of space in the boxes, so anything that goes over an edge will look clipped and ugly.

No, I was meaning more than that, I was saying to use the exact template, not just something like it. The problem is not clipping. What happens is that mipmapping...
Okay, you know how mipmapping works?
When the GPU is painting a texture on a surface, it kind of does a hopscotch over the texture for each scanline. At each jump it actually picks 8 texels (if you use tri-linear filtering, which you kinda must), 4 from one mipmap, 4 from another mipmap of the texture, then interpolates between them to get a final color for that pixel on the screen. Each mipmap is a reduced version of the previous, and there's many; but it first selects two based on distance. For mipmap generation (on the fly, as you load the texture onto the videocard): each reduction is by a factor of 2. So, if the original texture is 1k by 1k, next mipmap is 512 by 512, next is 256 by 256, and so on until the last mipmap is a single pixel. The reductions are done by filtering: averaging 4 texels to 1.
If you have a collection of small textures embedded into a big one, rather than just one big texture, and if the subtextures don't occupy power of two size squares properly aligned, the process of filtering to produce mipmaps will start to mix neighboring textures.
If the sub-textures ARE power-of-two -aligned, power-of-two -sized, they will only begin to mix at a much lower mipmap level; --essentially, by the time each subtexture is a single pixel, at which point you don't care.

But like I said, we can just try it like it is, disable mipmapping and trilinear filtering; just use bi-linear, and to hell with it. Now, any chance you could figure out what's crashing mesher, on your end?


Just gonna put here the code I was working on, so it doesn't get lost.

Code: Select all

/*
   Code WIP for producing a continuous field of crap to fly through. Basically,
   we got a circular queue class called "junkqueue" of ojects called "mesh_instance"
   implemented as an array. There's a mesh file with about 100 crappy objects,
   permanently sitting in video ram. The software instantiates these objects at
   random in front of your ship, and removes them once they are too far behind you,
   so as not to exceed the capacity of the queue.

   Positions:
   As the ship flies, objects are spawned at constant distance from the player. Such
   distance as causes a typical object to be 1 pixel in size. This is NOT z-depth,
   but actual distance; --i.e.: NOT a spawning 'plane', but a spawning 'hemisphere'.
   The position of each new object is decided by picking two random numbers of flat
   distribution. One is applied to angle from the ship's current speed vector. The
   other is applied to a 360 degree rotation around the speed vector. This will
   result in higher junk density towards the center, which is desirable for the sake
   of rendering efficiency, but can be compensated against later if it proves too
   obvious to the player. The frequency of spawning depends on speed and desired
   density of junk. Each object will be spawned with a random rotational position
   quaternion, a random quaternion for spin, and with a random velocity vector
   differential relative to the velocity vector passed in to the spawning call.
   (Essentially, if we're approaching a space station, surrounding junk are on the
   same orbit as the station. So the station's velocity vector is what we pass to
   the spawning routine. The velocity differentials will be zero most of the time,
   and in rare cases have like a walking speed difference with the vector passed
   in, to account for garbage that may have been hit by a passing ship.)

   Junkpicks:
   Pieces of junk are picked at random from the junk mesh of 100 or so models. But
   not all with the same probability. The simplest ones are picked the most often.
   Also, some of the objects can be randomly scaled in x, y and z; some can be
   scaled in (x,y) and z, meaning that x and y scalings must match, to keep these
   round objects round. Thirdly, there's a group of familiar, non-scalable objects.
   The available objects and their scalability and texture randomizability will be
   described via a text file, possibly xml, and the data put into a static array
   of objects of class "mesh_object".

   Texturepicks:
   There will be one texture (plus specular and normal map textures, but I will
   ignore these for simplicity of discussion), its size being 2k by 1k, RGBA.
   This one texture is actually made up of four "main textures", each 1k by 512.
   Each "main texture" is subdivided into 12 square subtextures at the left, each
   measuring 128 pixels on the side; plus 80 smaller square subtextures, 64 by 64
   each.
   Of the 12 larger subtextures, 9 are used for paper textures, including texts,
   photos, drawings and tax-forms. There are about 10 pieces of junk that look like
   warped square and rectangular surfaces. Any of them can be assigned any of the
   9 "paper" subtextures.
   The remaining 3 large subtextures are for box covers, which need better rez
   than most of the other junk. There's one cereal box and one software box among
   the 100 or so junk pieces.
   The rest of the junk are more geometrically complex and therefore require less
   texture detail, and thus only get a 64 by 64 subtexture each.
   In addition to randomizing 9 sub-textures for "papers", we pick one of the four
   main textures when spawning an object, so as to produce crappy variety.

   To do:
   * Finish this software crap. Hardest part will be the constructor, which has to
   initialize the whole junk field, not just the spawning range ahead...
   * Make new junk meshes specific to base type: food for agricultural; mechanical
   parts for industrial; additional bags and packaging for commercial; and organs,
   body parts, needles, gloves and stained bedsheets to float around medical space
   stations.
   * Make new junk meshes specific to factions (rlaan and aera items of furniture,
   clothing, foodstuffs, etc.)
   * Implement such that around each base we have 4 sources of floating crap: the
   generic junk, base-type junk, faction junk, and dangerous junk.
   * Make ship-interior junk, both for battlefield debris and to spawn inside ships
   as pieces of armor come off them during combat.
   * Consider using a detail texture, or better yet, a detail normal map; or better
   yet, a set of randomly pickable detailed normal maps.
*/
namespace junk
{

struct uv_offset
{
    float Du, Dv;
};
inline void random_main_texture( uv_offset & uv )
{
    int i = int( floor( 4.0f * rand() ) ); //assuming rand() returns 0.0 to 0.999...
    uv.Du = 0.5f * float( i & 1 );
    uv.DV = 0.5f * float( i >> 1 );
}
inline void random_paper_texture( uv_offset & uv );
{
    const float u_subtext_sz = 128.0f / 2048.0f; //subtext size/texture width
    const float v_subtext_sz = 128.0f / 1024.0f; //subtext size/texture hight
    random_main_texture( uv );
    int i = int( floor( 9.0f * rand() ) ); 
    uv.Du += u_subtext_sz * float( i / 3 );
    uv.Dv += v_subtext_sz * float( i % 3 );
}
class mesh_object //tbd
{
};
struct vector3d
{
    double x,y,z;
};
struct quat
{
    float w,x,y,z;
    void set_to_identity()
    {
        w=1.0f; x=y=z=0.0f;
    }
    void normalize()
    {
        if( w < 0.0f )
        {
            w=-w; x=-x; y=-y; z=-z;
        }
        float temp;
        while( 1 )
        {
            temp = r*r + h*h + i*i + j*j;
            if( temp > 0.1f ) break;
            w += 0.325f; //will ensure next loop breaks
        }
        temp = 1.0f / sqrtf(temp);
        w *= temp; x *= temp; y *= temp; z *= temp;
    }
    void randomize_spherically()
    {
        r = rand() - 0.5f; //assuming rand() returns 0.0 to 0.999...
        h = rand() - 0.5f;
        i = rand() - 0.5f;
        j = rand() - 0.5f;
        normalize();
    }
};
class mesh_instance
{
    vector3d pos, spd; //position and velocity
    quat rpos, rspd; //rotation and spin
}
class junkqueue
{
    mesh_instance array_[MAXJUNK];
    class circular_index
    {
        int i_;
        void fix(){ i_ &= (MAXJUNK-1); } //MAXJUNK must be power of two
    public:
        circular_index( int i = 0 ) : i_(i) { fix(); }
        int operator++() { ++i_; fix(); return i_; }
        int operator--() { --i_; fix(); return i_; }
    int spawn_iterator;
    int dump_iterator;
    //"next()" is admittedly not a very descriptive function name,
    //but this is one of those rare cases when something does so
    //much there's no appropriate name to give it. Before it allocates
    //the next cell in the queue, a sorting and weeding out pass is done
    //through the whole queue, to make sure there's room for a next...
    int next()
    {
        int i = input iterator + 1; if( i >= MAXJUNK ) i = 0;
        int j = input iterator - 1; if( j < 0 ) j = MAXJUNK;
        while( i != j )
        {
            ++i; if( i >= MAXJUNK ) i=0;
            if( array_[i].distance() > release_distance )
                array_[i].destroy();
            else
                break;
        }
        return ++input_iterator;
    }
public:
}

[Ryder P. Moses]

No, I got that. They're all in their little boxes. What I'm saying is that two faces that share an edge on the UV map may not share one on the model, so when texturing it's important to be sure that nothing obvious crosses an edge.

And... how 'bout I send you the .3ds file and you send it through Wings? I'm pretty sure no OBJ I produce is going to work in Mesher.

[chuck_starchaser]

I don't have wings, atm; only blender, which doesn't import 3ds, but I could see if blender opens the obj file, and if it does, try and save it again; mayb it might fix it; but I'll do it tomorrow; I didn't sleep last night at all and my brain is fried, and I'm hungry also. Got your email. So, tomorrow.