Calculation of a textures projection

many viewers, no replies?

to make that a bit more understood, why i need this information, i like to put that on our pioneer-wiki, there might some come along and make scripted models, one of the main problems for a inexperienced model scripter is texture handling. apart from animations with expressions, but i am relatively versatile in that, while some strange acting of texture still gives me a lot to think.

so i will link here additionally to the pioneer-wiki, mainly the texture models part.

http://pioneerspaces...delling#texture

please comment it if you have some experiences in that, you can even tell me that what i posted to the wiki is rubbish, that would help to, especially when you can explain it.

or is the task of scripting models really that unknown? i know i didn't found good answers no where.
yes, i am aware that this is a "primitive" way of modeling to most, while i and the project starting developer still believe it's the most sophisticated way.
it fits to a game like Pioneer and makes it different to other space sims.
further the use of scripts to bind models to a game (objects or generated geometry) is somewhat cool, there is not much you can't do with the model in the game.
basically you can let the model act to anything that happens in the game and animations with expressions are far smoother rather then the Matrix4x4 key frames stuff, which is lame compared to that imho.

personally i guess modelers should start exactly with this basic way of modeling, it gives you a different understanding of how geometry get's handled by computers.
due to that fact that most only use very high leveled programs to create models, they haven't any idea of the basics.

already polygon winding is a riddle to some, still some have problems what's behind a left handed or right handed coordinate system.
but, if you understand such you will better understand why you can't simply tear a model from a sectioned quad (you can but creases aren't the same on left and right side),
what's behind creases and how that stand in relation to the above named polygon winding. of course you can give your model simply many thousand polys and it get's somewhat smooth, but that's either lame imo.
you will better understand how a program animates a part and why the parts origin is of such a importance, many make nice models, perhaps far better looking then mine.
but have serious problems to animate a simple landing gear, without the problem that the animation later didn't works proper in the game, of course it has in the CAD program you made the model with, but such a program has correctional data which the final exported model simply doesn't has.

first
i need to know how to calculate the vectors when i change the ratio of the mesh, stretch it on only one vector, because i know it influences the corresponding other vector.[/quote]

I hope i get your question right. You want to know how to recalculate the position of the vertices, when you scale in one direction?
Well, you have a scale factor and you only scale in direction of your choice. you have to have a starting point (pivot element. mostly the zero vector).

then you have the actual position of your vertex.
Let us try this code:
float mScale=GetScaleFactor();
vec3 mPivot= new vec3(0,0,0); //just generating the zero vector
vec3 mVertexToScale= GetVertexThatIWantToScale();
// lets say you only want to scale a vertex into one direction. Let it be the x-axis in this case. Other Axis are similar to calculate
//As the second step we check if we have to check in which direction to scale
//this is pretty simple. just check if the relative position is positive or negative.
float tmpRelativePosition= mVertexToScale.x - mPivot.x; //for our example this is totally nonsene but i try to keep it as abstract as possible
//this part of the code is just written that way because i think it is better to understand. I think you have to take care of mScale gets negative but it is not hard to figure out what to do then.
if(mScale<1){ //scale towards the Pivot

mVertexToScale.x-=tmpRelativePosition*(1.0f-mScale); // the greater mScale is the less we scale

}
elseif(mScale>1){ //scale away from the pivot

mVertexToScale.x+=tmpRelativePosition*mScale; //the greater mScale is the more you scale

}

//that is pretty much it


second
is there a "rule" that i can use if the mesh's dimensions are in any one vector lower as 1 unit, i know also already that the value reasonably will be higher then 1, but it seems like 1.5 corresponds to a mesh's dimension of 0.5, can i follow this linear?[/quote]

Yes. if it is bigger than1 just look at the decimal places. If it is smaller than zero you have to take 1-decimalPlaces.


I hope you got your answer. If not please redescribe your problem.

Due to the fact that UV coordinates are stored relatively you do not have to recalculate them if you scale your object.
€dit: The Texture may look streched if you scale but that is the way it goes.
In case that you wanted to Scale the UV coordinates: It functions just the way i wrote above. instead of 3d vectors you use 2d vectors.

many viewers, no replies?
or is the task of scripting models really that unknown? i know i didn't found good answers no where.

Your terminology and question are a bit muddled. I'm not exactly sure what you're asking, besides that it's got something to do with calculating some kind of texture coordinate projection for some kind of implicit surface... Both are well-known areas of study, so there's definitely good information out there somewhere.

What does "equals to quadratic" mean? What is the "mesh's corresponding vector"? What's special about things less than 1 unit that makes the calculations change? What is this connection between the numbers 1.5 and 0.5? I fear something has been lost in translation.

thanks for your replies, i hope it will help me

i translate myself , maybe that makes it less easy sometimes, i know (it's only good i dont' transpose myself )

stupid me i rolled up the question from the wrong side.

usually one would say texture projection that's the proper term, but this leads imo to a wrong imagination, because the texture stays always 1:1

and when projecting a texture in a script in the manner of texture('some' v(0,0,0), v(1,0,0),v(0,1,0)) you actually have to divide 1 with the dimensions of the mesh in the projected plane (U,V).
to get then something like texture('some',v(0,0,0),v(0.0025,0,0),v(0,0.5,0)) that works i know .

so this i know already, it's only what happens when one dimension of the mesh is below 1 unit, i experienced 1.5 ".....v(1.5,0,0),v(0,1,0) in the projection expression fits then to a dimension of 0.5 units of the mesh, but first i'm not sure and second i have no idea if i can follow that linear, would mean a side length of 0.25 is then 2? and if what is the reason behind? it's logical that the value has to get above 1 but in what manner? by nature i would suggest 0.5 unit in either U or V results in 2 for the projection, but that didn't fits.

and further there is another a bit odd behaviour, for a x,y projection i have to calculate both, for a x,z projection i can leave z (V) 1 why this? this is a bit confusing and when i like to explain that to even less experienced it gets weird.

a further problem is when i "stretch" not the mesh, the projection i.e U, means when it overlaps why or how does that influence the other vector (V)? somehow i understand the space must be kept.
so i can't stretch one projection vector without that the other gets smaller. i guess that's the reason.

due to such i never managed it to scale a mesh and the texture always in the same manner.

as example, i liked to make a standard undercarriage for a aircraft / spaceship, i set up a function who generates the the parts for me by variables, so i can give the Under Carriage every size in any vector.
now everything was fine, except for the wheels itself the texture has fit then only every 0.5 units i scaled the model, any other it's displaced and i found no way to move the texture with the scale. it scales only one vector z, the wheel is left untouched it stays in the same size, so it's only a translation for the wheel, for the rest like the recess and pistons it's a scaling, else i would get a oval wheel .

but i guess this goes a bit far and i would be happy only to know how i have to calculate the first reported case, what do i have to calculate if the mesh's dimension get's below 1 unit.

in words this is a bit stupid to explain, maybe i should attach some examples, that will make it far easier.

i guess somehow i start right now to understand, the texture has a given size if take some away from one vector i have to add it to the other, right? but i guess it's not a simple subtraction / addition

maybe a link to something that's fully explaining this behavior can help me, but like i said i haven't found much useful articles about that. usually no one does it this way today, each is using CAD and U.V mapping of tris. and simply outputs a textured model.

but yes, i guess to, that it should be a known problem, even more, it's basic to know such (but only if you script models or like to get deeper into the matter).

it's a bit like polygon winding, who cares today about such? when using CAD and have no idea and not to care for, whats going on inside.

while i'm struggling with with all kinds of math and geometry to get a model, to get it textured and animated finally