Pandora Tincs - Multiplayer Shooter For Pandora (video)


Now that makes more sense :p

I don't know why I didn't realize that before. I made the decision that 8 was a smaller number than 24, so it would be best to not have vertices in the same positions.

But that's just how Blender handed me the cube. If I was to model, or get a correct model, it would look right?

That's why, Giovannis gun looks fine?

34520ee.jpg


^^ Picture of the text cube you gave me being rendered.
 
Last edited by a moderator:
'Butterman' said:
Now that makes more sense :p

I dont know why I didnt realize that before. I made the decision that 8 was a smaller number than 24, so it would be best to not have vertices in the same positions.
every vertex in a mesh is a record/structure of a pre-established fixed format, keeping various vertex attributes (position, normal, texcoords, etc). when you create meshes from a model, some vertices will be instantiated more than once in your mesh, depending on variations in the individual vertex attributes, and/or mesh connectivity needs. so a model of N vertices may (not necessarily, though) translate to a mesh of more than N vertices. of course, those vertex instances will share at least their position attribute, maybe other too.

QUOTE
But that is just how Blender handed me the cube. If I was to model, or get a correct model, it would look right?

hopefully. this is where the correctness of the exporter comes into play. try assigning proper smoothing groups to a cube in blender, using that tutorial i linked-up earlier, and export again to see if the smoothing groups were honored.
 
Last edited by a moderator:
I followed that little tutorial, I just selected all faces and pressed "P". Still the same 8 vertex cube came out.

I'm not sure why, but light isn't working correctly on the cube you sent me. Like, light seems to light up the whole face, not gradually getting darker as distance as increased like on the 8 vertex ones. Well it gets gradually darker, but all at once. Until we get past that critical angle and light goes bye bye. In my cubes, I get a really cool effect where light goes away, circularly, like you would expect with a point light sitting next to a rotating cube.
 
Last edited by a moderator:
Try turning on backface culling. Then any faces that are the wrong way will become apparent (they'll only be visible from one angle).
In Blender, in the edit panel (select object->F9) and then in the Mesh tab, uncheck "double sided" to turn on backface culling in Blender. Use the face select tool (the triangle with a dot in it), or select all the relevant vertices, then press "flip normal" in the Mesh Tools tab.
Or select many vertices and hit ctrl+N to recalculate normals.
Graphics programming can be a real bitch if you don't fully understand the process of modeler->app. Spend a day or two playing around in Blender and things become a lot clearer.

Tobs
 
Last edited by a moderator:
'Butterman' said:
I followed that little tutorial, I just selected all faces and pressed "P". Still the same 8 vertex cube came out.
so you created one smoothing group for the whole cube? that is not what you were meant to do.

you need at least 3 smoothing groups to create a properly-connected cube mesh - one for every two sides along each of the +/- x/y/z directions (assuming an axis-aligned model). alternatively, you can go 1:1 groups-to-sides of the cube, producing 6 groups.

QUOTE
I am not sure why, but light isnt working correctly on the cube you sent me. Like, light seems to light up the whole face, not gradually getting darker as distance as increased like on the 8 vertex ones. Well it gets gradually darker, but all at once. Until we get past that critical angle and light goes bye bye. In my cubes, I get a really cool effect where light goes away, circularly, like you would expect with a point light sitting next to a rotating cube.


i can assure you the problem is not in the cube. a big deal of your original model's light fall-off behavior had to do with wrong normal angles, not distances. time to post your shader code so we can figure out what you are doing/expecting wrong.
 
Last edited by a moderator:
'darkblu' said:
'Butterman' said:
I followed that little tutorial, I just selected all faces and pressed "P". Still the same 8 vertex cube came out.
so you created one smoothing group for the whole cube? that is not what you were meant to do.

you need at least 3 smoothing groups to create a properly-connected cube mesh - one for every two sides along each of the +/- x/y/z directions (assuming an axis-aligned model). alternatively, you can go 1:1 groups-to-sides of the cube, producing 6 groups.

QUOTE
I am not sure why, but light isnt working correctly on the cube you sent me. Like, light seems to light up the whole face, not gradually getting darker as distance as increased like on the 8 vertex ones. Well it gets gradually darker, but all at once. Until we get past that critical angle and light goes bye bye. In my cubes, I get a really cool effect where light goes away, circularly, like you would expect with a point light sitting next to a rotating cube.


i can assure you the problem is not in the cube. a big deal of your original model's light fall-off behavior had to do with wrong normal angles, not distances. time to post your shader code so we can figure out what you are doing/expecting wrong.


Good idea, I'll comment it and upload after dinner.
 
Last edited by a moderator:
Here we go, enjoy!
CODE

//TINCS Vertex Shader

varying vec3 lightDirection,normal;
varying float Power, lightDistance;
varying vec3 halfV;

//I get my eyeDIR (eye direction vector, for specular) and lightPOS (light position vector) from the APP
uniform vec3 eyeDIR;
uniform vec3 lightPOS;

void main()
{
//Strangly, passing the lightPOS from the APP as a uniform 3f shizzle won't work (the eye does...), so i have to set it here if i wanna change it
lightPOS = vec3(0,0,0);

//I need the world position of the vertex, so i can get a direction vector between it and the light
vec3 calculatedVertex = gl_ModelViewMatrix * gl_Vertex;

//I need the light-vertex vector, to grab direction and distance off
vec3 lightVertexVec = lightPOS - calculatedVertex;

//Now, I normalize the light-vertex vector to get the direction of the light to the vertex
lightDirection = normalize(lightVertexVec);
//Then I just get the length for distance
lightDistance = length(lightVertexVec);

//Make sure everything that needs to be applied to the normal is
normal = normalize(gl_NormalMatrix * gl_Normal);

//Calculate the halfVector, (for specular stuff) I think this code might be dodgey! Take a good look darkblu :p
halfV = normalize((lightDirection + (vec4(eyeDIR.x,eyeDIR.y,eyeDIR.z,0) * gl_ProjectionMatrix * gl_ModelViewMatrix)) / 2);

//We only need one set of vertex co-ordinates
gl_TexCoord[0] = gl_MultiTexCoord0;

//Optmized setting of position
gl_Position = ftransform();
}


CODE
//TINCS Fragment Shader

//sampler2D for diffuse map and specular map
uniform sampler2D tex, spec;
varying vec3 lightDirection,normal;
varying float Power, lightDistance;
varying vec3 halfV;

void main()
{

//I store the final specular value in a single float
float specPower;
vec4 specular;
float specFinal;

//Att = multiplyer for light distance stuff
float att;

//Quick ambient, I'm going to set ambient to uniform when i link it in with TINCS, so map makers can set it
vec4 ambient = vec4(0.02,0.02,0.02,0.02);
vec4 color = ambient;

//Cacluate the power of the light, by getting the dot product of the normal and light direction
Power = max(dot(normalize(normal), normalize(lightDirection)),0.0);

//Get the diffuse value off the texture and if there is no diffuse, we set it to white
vec4 diffuse = texture2D(tex,gl_TexCoord[0].st);

if(diffuse == 0)
{
diffuse = vec4(1,1,1,1);
}

//Get the specular value off the specular texture
specular = texture2D(spec,gl_TexCoord[0].st);

//We don't want to waste time calcuating somthing that's going to be multplied by zero
if(Power > 0.0)
{
//attenuation equals one over the linear and quadratic power of the light, lower you go, the more powerful the light is
att = 1 / (0.01 * lightDistance + 0.01 * lightDistance * lightDistance);

//add the diffuse values onto the final color
color += att * (diffuse * Power);

//I've taken out the spec stuff for now, so we can solve this
//specPower = max(dot(normal, halfV),0.0);
//specFinal = 1 * pow(specPower,64.0);
//color += specFinal;
}

//Get the final color!
gl_FragColor = att * color;
}
 
Last edited by a moderator:
Mouse look and support for whatever stupid resolution you can think of works. So don't ask me if it supports X/Y resolution, it does.

While Darkblu gives me a hand with whatever shader problems I'm having, I'm working on the Windows client. The Pandora one is pretty much sorted, apart from porting it over to ES 2.0. Stuff like mouse look will work on the Pandora if you plug in a mouse.
 
Last edited by a moderator:
ok, first things first.

branching out code "for not wasting time" in a fragment shader is a bit of a wishful thinking - chances are all the code in your shader (not subject to JIT compile reductions) will be executed - that means all braches - due to the fact that the partial derivative instructions cannot function otherwise, and even though the standard allows undefined behavior of partial derivatives under such conditions, you are entirely at the discretion of the compiler; if it decided that it would rather not branch but mask out your if-ed block, then you could just as well take a performance hit! so careful with that branching there.

second, that half-vector computation in the vert shader is throwing me off. what space does that eyeDir originate from so that you would transform it by the transpose of the projection (!) and model-view matrices? given you eventually need that half-vector in view space, anyway? and then divided by 2 just before normalization? frankly, that computation looks rather random to me i.e. it is beyond iffy (or there is some utterly obscure spatial outsourcing going on the app side there).

from there on:

aside from the fact that your light source is fixed in view space (not in world space - there are no such built-in matrices in ogl), your diffuse computations look normal. except for one thing:

the per-vertex computation of the distance to light source which is then interpolated for the fragment shader would not work correctly for close-enough sources/large-enough flat surfaces.

consider the case when the light source is very close to the middle of a large flat surface - then vertices are far from the source, but the middle is close. but your per-vertex computation cannot handle this - according to it the distance between the light and the middle of the surface is about as big as the distance to the edges of the surface. are you following me?
 
Yup, I had that very same problem. That's why I broke that little test render up into tiles. Or whatever you like to call them :D.

What's the fix to that? And how can I get my light source into world space?

The if/else stuff and eye dir stuff is all I could gather up from various tutorials. My knowledge only goes as far as basic lambert lights. The tutorial used a half vector, taken off the fixed function light, I can't use fixed function, so that's me trying to calculate the half vector myself.

Thanks for the help.
 
Last edited by a moderator:
'Butterman' said:
Yup, I had that very same problem. That's why I broke that little test render up into tiles. Or whatever you like to call them :D.

What's the fix to that?

simple. dont compute a normalized light direction in the vertex shader - leave it as a difference between light source and vertex, then take the lenght measure from that in the fragment shader, and only then normalize your light dir.

QUOTE
And how can I get my light source into world space?

why do you want your light source exactly in world space? you need it to interact with your mesh in some arbitrary space - it could be (almost) any other space. object space is just fine. view space - either.

QUOTE
The if/else stuff and eye dir stuff is all I could gather up from various tutorials. My knowledge only goes as far as basic lambert lights. The tutorial used a half vector, taken off the fixed function light, I can't use fixed function, so that's me trying to calculate the half vector myself.
the half vector is nothing special - it is the (normalized) sum of the vertex-to-light-source and vertex-to-viewer vectors (again, both normalized on the input of the computation). and you can easilly compute those too - the former the way you already do it, and the latter is your vertex past the model-view transform, taken with the opposite sign. you just need to make up your mind in what space you will be carrying out your lighting computations. for your current setup, i would advise you to stay in view space.
 
Last edited by a moderator:
butterman, what are the chances of getting coloured lighting?

i'd like to use colour queues in my level design, identifying certain corridors and what not.

also, this tincs thread is hitting 32 pages long, at some point, are we able to create another dedicated to art/design/code etc??

or are you content with just putting everything into this?


its gone quiet on the backstories, hasn't it?
 
Last edited by a moderator:
I've made a few changes already darkblu, I'll look at making some more tonight. Looks good so far.

Could anybody make me a .blend cube with correct smoothing groups? :/

Yea, retort we will have different colored lights in levels. Urm, once we choose a name, we can get our very own forums courtesy of GPSchnyder, so we've just gotta wait until then. Yeah, no backstories recently, I haven't seen muzz around for a few days either, maybe he's cooling off.
 
Last edited by a moderator:
For a name, I'd honestly say stick with TINCS. It's a pretty catchy name, and seeing as that's what it's coming to be known by, changing it could confuse people. 473 posts in the development thread plus an art thread in General has publicized this name enough that I think we should leave it.
 
Last edited by a moderator:
Ok, thats an great idea, vorporeal , also:

Tin + CS = TinCS

QUOTE
tin (tn)
n.
1. Symbol Sn A malleable, silvery metallic element obtained chiefly from cassiterite. It is used to coat other metals to prevent corrosion and is a part of numerous alloys, such as soft solder, pewter, type metal, and bronze. Atomic number 50; atomic weight 118.71; melting point 231.89°C; boiling point 2,270°C; specific gravity 7.31; valence 2, 4. See Table at element.
2. Tin plate.
3. A container or box made of tin plate.
4. Chiefly British
a. A container for preserved foodstuffs; a can.
b. The contents of such a container.
tr.v. tinned, tin·ning, tins
1. To plate or coat with tin.
2. Chiefly British To preserve or pack in tins; can.
adj.
1. Of, relating to, or made of tin.
2.
a. Constructed of inferior material.
b. Spurious.




Counterstrike made of tin makes soem sense to me.
 
Or maybe just TINCS meaning "This is Not CounterStrike"? That was the whole point behind the name initially; the idea is that it isn't CS, not a variant of it (TinCS, TinyCS).
 
Last edited by a moderator:
Hah... Im not dead nor resting... i was moving house and had some network problems, its all sorted out now.

Working on some more concept art.... with actual paint so it will take a day or 2 but is looking sweet already. I'm also learning alot about making environments this trimester at college, and so my assessments will all be based around this game, even if i have to do them higher rez, than usable in game. It might be a good chance to make an enviro suitable for a cut scene.

Anyways im not in a house with a room big enough to actually use all my art stuff, so my production and output will increase.Now all i need is a new computer and im set.

I dont really like tincs as a name... but im thinking. For some reason Ive always thought calling a game "gaunt" would be cool, It also can bring in some user meaning.

"lean, angular and bony; haggard, drawn and emaciated; bleak, barren and desolate"
 
Last edited by a moderator:
'Muzz' said:
I dont really like tincs as a name... but im thinking. For some reason Ive always thought calling a game "gaunt" would be cool, It also can bring in some user meaning.

"lean, angular and bony; haggard, drawn and emaciated; bleak, barren and desolate"
Gaunt sounds cool. Should be put on the List for sure.
I'm right now working on the jottit Site to add some Soundideas to it. I've uploaded a Demosong also to explain my Idea. Take a look here:
CODE
http://tincs.jottit.com/music


And yeah, we need some other place for this. I'll build a site when the Name has been chosen. I'll do a Blog plus Forum. This way the "Departments" can discuss in the Forums and post done Ideas or polls on the Blog. Wikis are cool, but tend to get messy (as you see) if there is not that much work put in. Forums are easier to develope imho, as the threads tend to go away if getting irrelevant, but stay there. If we take a Forum like bb-press there are tags to attach to the posts which make them easy to find if looking for something special...
 
Last edited by a moderator:
'Vorporeal' said:
Or maybe just TINCS meaning "This is Not CounterStrike"? That was the whole point behind the name initially; the idea is that it isn't CS, not a variant of it (TinCS, TinyCS).
TBH, I really don't like TINCS as a name. It's saying it, I just can't say it to people.


'Muzz' said:
Hah... Im not dead nor resting... i was moving house and had some network problems, its all sorted out now.

Working on some more concept art.... with actual paint so it will take a day or 2 but is looking sweet already. I'm also learning alot about making environments this trimester at college, and so my assessments will all be based around this game, even if i have to do them higher rez, than usable in game. It might be a good chance to make an enviro suitable for a cut scene.

Anyways im not in a house with a room big enough to actually use all my art stuff, so my production and output will increase.Now all i need is a new computer and im set.

I dont really like tincs as a name... but im thinking. For some reason Ive always thought calling a game "gaunt" would be cool, It also can bring in some user meaning.

"lean, angular and bony; haggard, drawn and emaciated; bleak, barren and desolate"
Haha. Damn, not dead, maybe next time. :p

I like Gaunt. The meaning fits well with the art style.

Dictionary: gaunt (gônt) pronunciation

1. Thin and bony; angular. See synonyms at lean2.
2. Emaciated and haggard; drawn.
3. Bleak and desolate; barren.

'GPSchnyder' said:
Gaunt sounds cool. Should be put on the List for sure.
I'm right now working on the jottit Site to add some Soundideas to it. I've uploaded a Demosong also to explain my Idea. Take a look here:
CODE
http://tincs.jottit.com/music
And yeah, we need some other place for this. I'll build a site when the Name has been chosen. I'll do a Blog plus Forum. This way the "Departments" can discuss in the Forums and post done Ideas or polls on the Blog. Wikis are cool, but tend to get messy (as you see) if there is not that much work put in. Forums are easier to develope imho, as the threads tend to go away if getting irrelevant, but stay there. If we take a Forum like bb-press there are tags to attach to the posts which make them easy to find if looking for something special...


I like the music, some talent you've got there. We definitely need to mix it depending on the current pace, rather than the system you've created, what about a sound change when combat starts? We would have to test them both out, see which one works best. Music makes all the difference in an FPS, Half-Life 2 pulled it off perfectly, you would have times with almost no sound, that fit the scene perfectly, then, you would get in a huge battle and some really fast rock/dance would come on. It really changed the atmosphere.

Yeah, I like the idea of having just a forum rather than a wiki. But I think we should just continue to use the Jottit along side the forum, the Jottit is full of ideas and collaboration, it's becoming a good knowledge base.
 
Last edited by a moderator:
Back
Top