Where on earth are the UV source files ?

Compiling, libraries, modules, coding guidelines and porting

Moderators: jesterKing, stiv

Money_YaY!
Posts: 876
Joined: Wed Oct 23, 2002 2:47 pm

Where on earth are the UV source files ?

Postby Money_YaY! » Tue May 20, 2003 12:24 am

Picking at this code gives me a head ache. This file here, needs this file there. .... that file this ......

Could somebody tell me were the UV code files are located in the source.
I can find everything else, like mesh and even S-Mesh.

But no UV.

thorax
Posts: 320
Joined: Sun Oct 27, 2002 6:45 am
Contact:

Re: Where on earth are the UV source files ?

Postby thorax » Tue May 20, 2003 4:47 am

Money_YaY! wrote:Picking at this code gives me a head ache. This file here, needs this file there. .... that file this ......

Could somebody tell me were the UV code files are located in the source.
I can find everything else, like mesh and even S-Mesh.

But no UV.


Interesting the gameengine source is in C++ but blender source is in C..

Do a

fgrep -ri uv * | grep '\.h'

that recursively searches all subdirectories for anything matching "uv" (case insensatively) that contains the text '.h' which assumes we are looking for header files (which contain structures for data) that contain the UV coordinate parameters.. This is assuming th the UV parameters will be called as with the keyword "uv".. If they are not, there is
no choice but to read the code and look for uses of presumed UV coordinates..

Money_YaY!
Posts: 876
Joined: Wed Oct 23, 2002 2:47 pm

Postby Money_YaY! » Tue May 20, 2003 5:21 am

Oh boy , does it ever. A search for uv pulls 400+ slots.
I remembered that I have project builder. And there
are zero files named uv. All of the uv system methods are
strung all over the place { should of know } Mostly in mesh files.
arrrrgggg
And texture painting is a mystery.

VelikM
Posts: 80
Joined: Mon Oct 14, 2002 4:18 am

Postby VelikM » Tue May 20, 2003 7:43 am

Some of the UV stuff is in blender/source/blender/src/editface.c

Money_YaY!
Posts: 876
Joined: Wed Oct 23, 2002 2:47 pm

Postby Money_YaY! » Tue May 20, 2003 2:43 pm

Thankyou. Now if you know where Texture Painting is.
That to would help.

thorax
Posts: 320
Joined: Sun Oct 27, 2002 6:45 am
Contact:

Postby thorax » Tue May 20, 2003 10:45 pm

Money_YaY! wrote:Thankyou. Now if you know where Texture Painting is.
That to would help.


with

fgrep -ir texture * | grep -i paint

I was able to find some constant G_TEXTUREPAINT,

Code: Select all

$ fgrep -r G_TEXTUREPAINT *

source/blender/blenkernel/BKE_global.h:#define G_TEXTUREPAINT   65536
source/blender/src/poseobject.c:        G.f &= ~(G_VERTEXPAINT | G_FACESELECT | G_TEXTUREPAINT | G_WEIGHTPAINT);
source/blender/src/buttons.c:   } else if (G.f & G_TEXTUREPAINT) {
source/blender/src/space.c:                             if (G.obedit || !(G.f&(G_VERTEXPAINT|G_WEIGHTPAINT|G_TEXTUREPAINT))) {
source/blender/src/space.c:                             else if (G.f & G_TEXTUREPAINT) {
source/blender/src/space.c:                             else if( G.f & (G_VERTEXPAINT|G_TEXTUREPAINT)) sample_vpaint();
source/blender/src/drawmesh.c:          int editing= (G.f & (G_VERTEXPAINT+G_FACESELECT+G_TEXTUREPAINT+G_WEIGHTPAINT)) && (ob==((G.sc
ene->basact) ? (G.scene->basact->object) : 0));
source/blender/src/drawobject.c:        vertexpaint= (G.f & (G_VERTEXPAINT+G_FACESELECT+G_TEXTUREPAINT+G_WEIGHTPAINT)) && (ob==((G.sc
ene->basact) ? (G.scene->basact->object) : 0));
source/blender/src/drawobject.c:                                int vertexpaint= (G.f & (G_VERTEXPAINT+G_FACESELECT+G_TEXTUREPAINT+G_
WEIGHTPAINT)) && (ob==((G.scene->basact) ? (G.scene->basact->object) : 0));
source/blender/src/drawobject.c:                        if( G.f & (G_VERTEXPAINT+G_TEXTUREPAINT)) {
source/blender/src/drawobject.c:        if(ob==((G.scene->basact) ? (G.scene->basact->object) : 0) && (G.f & (G_FACESELECT+G_VERTEXPA
INT+G_TEXTUREPAINT+G_WEIGHTPAINT))) {
source/blender/src/drawobject.c:        else if((G.f & (G_VERTEXPAINT|G_FACESELECT|G_TEXTUREPAINT|G_WEIGHTPAINT))==0) {
source/blender/src/drawview.c:  if(G.f & (G_VERTEXPAINT|G_FACESELECT|G_TEXTUREPAINT|G_WEIGHTPAINT));
source/blender/src/drawview.c:  if(G.f & (G_VERTEXPAINT|G_FACESELECT|G_TEXTUREPAINT|G_WEIGHTPAINT)) {
source/blender/src/drawview.c:  if(G.f & (G_VERTEXPAINT|G_FACESELECT|G_TEXTUREPAINT|G_WEIGHTPAINT)) {
source/blender/src/edit.c:      else if(G.f & (G_FACESELECT + G_VERTEXPAINT + G_TEXTUREPAINT +G_WEIGHTPAINT)) {
source/blender/src/editface.c:  else if((G.f & (G_WEIGHTPAINT|G_VERTEXPAINT|G_TEXTUREPAINT))==0) {
source/blender/src/editmesh.c:  G.f &= ~(G_VERTEXPAINT+G_FACESELECT+G_TEXTUREPAINT);
source/blender/src/editobject.c:        G.f &= ~(G_VERTEXPAINT+G_FACESELECT+G_TEXTUREPAINT+G_WEIGHTPAINT);
source/blender/src/editobject.c:        G.f &= ~(G_VERTEXPAINT+G_FACESELECT+G_TEXTUREPAINT+G_WEIGHTPAINT);
source/blender/src/editview.c:          if(G.f & (G_VERTEXPAINT+G_FACESELECT+G_TEXTUREPAINT+G_WEIGHTPAINT)) allqueue(REDRAWVIEW3D, 0)
;
source/blender/src/headerbuttons.c:             if (G.f & G_TEXTUREPAINT) {
source/blender/src/headerbuttons.c:                     G.f &= ~G_TEXTUREPAINT;
source/blender/src/headerbuttons.c:             if ((!(G.f & G_WEIGHTPAINT)) && (G.f & G_TEXTUREPAINT)) {
source/blender/src/headerbuttons.c:                     G.f &= ~G_TEXTUREPAINT;
source/blender/src/headerbuttons.c:             if ((!(G.f & G_VERTEXPAINT)) && (G.f & G_TEXTUREPAINT)) {
source/blender/src/headerbuttons.c:                     G.f &= ~G_TEXTUREPAINT;
source/blender/src/headerbuttons.c:             if (G.f & G_TEXTUREPAINT) {
source/blender/src/headerbuttons.c:                     G.f &= ~G_TEXTUREPAINT;
source/blender/src/headerbuttons.c:                             G.f |= G_TEXTUREPAINT;
source/blender/src/headerbuttons.c:     if (G.f & G_TEXTUREPAINT) G.vd->flag |= V3D_TEXTUREPAINT;



Note that G.f seems to be a flag container, the G_TEXTUREPAINT is a
mask, that's why "&" is used to mask off the bits that represent
G_TEXTUREPAINT mode.. I think the "G_" part of the name means
that this is a global state (which have I been saying about global variables, can I say they are evil now?).. So in order to affect the
TEXTURE paint mode you have to locate all the places where the
state is checked to see if its in TEXTUREPAINT mode, then
it performs certain operations on the state.. This means everywhere the
state is check you have to consider these in order to add yoru feature..

The better way to do this would be to put all the texture paint
features in a single object and remove all the condition checking,
as the global state is open to be changed by any code in blender..
And there is no way of enforcing how code in other parts of
blender will change this state information, its relying a lot of the
experience of the coder, which is soooooo wrong.

It would be very easy for me to add G.f =/ 7; and blender's
bit flag would shift in meaning an the state is indeterminate,
because I just took a bit flag and performed a division operation on
it, assuming it was a number and not a bit-flag.. This may not happen intentionally, but what if it was a typo and I was really meaning to say
G.f =& 7? Nobody will find this bug because the syntax is
proper, its the semantics that are wrong and no computer can determine faulty semantics.. That's why we need to document blender's source
immediately and plan a re-design..

It seems that "G" is an effort to localize the scope of the global
flags.. G should have some methods:

isInTexturePaintMode()
isInVetrexPaintMode()

etc..

so we can do (later once blender is in C++)

if (GlobalState.isInTexturePaintMode()) {
MyObject.texturepaint.doThisFunction(12,34);
// MyObject is the geometry, texturepaint is a sub-child of the geometry,
// thus we are performing a texturepaint oriented operation
// on the geometry.
// doThisFunction() knows which object this is being performed because
// its being referenced in relation to it..
// who knows what "12,34" are, these are parameters, but
// the method interface for "doThisFunction()" in the "texturepaint"
// sub-child of the Geometry "MyObject" should outline the use of 12,34.
}

Instead of doing

// mask off the bits the determine the TEXTURE PAINT mode from
// the global state container.. If the result of the mask is greater than
// 0, most C compilers interpret values more than 0 to be a true
// boolean condition, thus the following code is executed.

if (G.f & G_TEXTUREPAINT) {
doThisFunctionOn(SelectedObject, 12, 34, G_TEXTUREPAINT);

// SelectedObject is a void pointer to a structure of unknown size,
// its assumed the first member of this structure is the length of the
// structure, but a check is done to make sure the structure is not a NULL
// pointer. The kind of "doThisFunctionOn" that is performed is determined
// by "G_TEXTUREPAINT" flag, 12 and 34 are the parameters.
}

The assumption though is that all C compilers assume values more
than 0 to be a "true" state.. What if some C compilers interpret
variables that are stored in Integers to have an extra condition,
where values less than 0 are negative and values above 0 are positive..
And 0 is indetereminate.. Then the assumptions on which the falg checking routines in blender's source are based, will fail.
However a method on an object that checks in plain english for
"isInThisState()" will be easily fixed because the condition checking
code is in a method of an object, its not in every ".c" file throughout
the source code base, I don't have to change every conditional to look like

if ((B.f & G_TEXTUREPAINT) > 0) {
}

I just change the method "isInTexturePaintMode()" that reveals
the boolean result true or false, without the code that uses it inheriting
from its internal complexities.. This is design, and its purely relevant..

Note in C source "~" mean flip the bits of the given variable.. And
"&=" means mask off and assign these bits..

So

G.f &= ~(G_VERTEXPAINT+G_FACESELECT+G_TEXTUREPAINT+G_WEIGHTPAINT);


Means mask off all bits relating to the VERTEXPAINT, FACESELECT, TEXTUREPAINT, WEIGHTPAINT modes.. This is probably a modification made to the global state of blender made when coming out of
some mode that required these flags..

It would have been better just to do

G.exitUVEditMode()

which is probably what its meaning to do.. Or is it

G.exitVertexPaintMode()

or is it

G.clearVertexPaintModes()


Who knows.. That code doesn't offer much description..

SirDude
Posts: 941
Joined: Sun Oct 13, 2002 7:37 pm
Location: University of Minnesota (USA)
Contact:

Postby SirDude » Wed May 21, 2003 4:34 pm

another nice utility besides grep is cscope
You type in a functionname, define etc... and it
tells you all of the files its in. If you haven't
played with it I would give it a try.


Return to “Coding Blender”

Who is online

Users browsing this forum: No registered users and 0 guests