We closed this forum 18 June 2010. It has served us well since 2005 as the ALPHA forum did before it from 2002 to 2005. New discussions are ongoing at the new URL http://forum.processing.org. You'll need to sign up and get a new user account. We're sorry about that inconvenience, but we think it's better in the long run. The content on this forum will remain online.
IndexProcessing DevelopmentLibraries,  Tool Development › SAITO OBJ Loader material fix
Pages: 1 2 
SAITO OBJ Loader material fix (Read 7588 times)
SAITO OBJ Loader material fix
May 19th, 2007, 12:57am
 
Hi All,

I've had to do a lot of work with obj models this week so I needed to find a fix for the bug mentioned by kof in this post http://processing.org/discourse/yabb_beta/YaBB.cgi?board=os_libraries_tools;action=display;num=1114999115;start=30#30

So after looking at the source posted by Saito on the lib site http://users.design.ucla.edu/~tatsuyas/tools/objloader/index.htm I think this problem can be fixed by changing this line in the OBJModel.java file

Quote:


parent.vertex(-v.vx, v.vy, v.vz, 1.0f - vt.vx, vt.vy);


change to
Quote:


parent.vertex(-v.vx, v.vy, v.vz, vt.vx, 1.0f - vt.vy);



and the UV's are the correct way up.

Also adding this bit of code to the bottom of the same file (before the last bracket) allows for texture swapping on the OBJ model

Quote:

public void setTexture(PImage textureName) {
 texture = textureName;
}
// OBJModel.setTexture(PImage);


Hope this helps

mattD(polymonkey);
Re: SAITO OBJ Loader material fix
Reply #1 - May 29th, 2007, 4:57am
 
Thanks.
I just updated the library.

http://users.design.ucla.edu/~tatsuyas/tools/objloader/index.htm

I did't realize that the tex coodinate is inversed. (I thought it worked fine a long time ago on processing. Maybe I was wrong.)
Also texture swapping is a good suggestion. I put your code in the library.
Re: SAITO OBJ Loader material fix
Reply #2 - May 31st, 2007, 1:59am
 
I just wanted to tip you off to another OBJ loader bug, I've posted it here:

http://processing.org/discourse/yabb_beta/YaBB.cgi?board=LibraryProblems;action=display;num=1179976974;start=0

Re: SAITO OBJ Loader material fix
Reply #3 - Jun 6th, 2007, 8:32am
 
Thanks for the update SAITO. But I added an extra bit to the material loader. I'm not sure if anyone else will find this useful but here goes. The mtl file contains an absolute path to the texture applied to the model. I had a lot of obj files and I needed to make sure that they would only load the files that were in the processing data folder. So I added a bit of code that stripped out the end filename from the path string. here it is.

All this code lives in OBJModel.java

first a boolean and a couple of functions need to be added to the class OBJModel

Quote:

boolean flagLocalTexture = false;

public void enableLocalTexture() {
 flagLocalTexture = true;
}

public void disableLocalTexture() {
 flagLocalTexture = false;
}


Next this code is dropped into the mtl file parser. It replaces the current section that reads the map_Kd line. It's located in the void parseMTL(BufferedReader bread) function.

Quote:

else if (elements[0].equals("map_Kd")&& elements.length > 1) {

 //--------------------------------------------------- start MattD(polymonkey) hack

 if(!flagLocalTexture){

   debug.println("\ttexture diffuse '" + elements[1] +"'");

 }

 String texname = elements[1];

 if(flagLocalTexture){

   int p1 = 0;

   String slash = "\\";

   while (p1 != -1){

        p1 = texname.indexOf(slash);

        texname =  texname.substring(p1+1);

   }
   
 debug.println("\tlocal texture diffuse '" + texname +"'");

 }

 //--------------------------------------------------- end MattD(polymonkey) hack        

 currentMtl.map_Kd = parent.loadImage(texname);

}



So after all that if you do this

Quote:

OBJModel model;

void setup()
{
 model = new OBJModel(this);
 model.enableLocalTexture();
 model.load("dma.obj");
}


Then it will only load the texture files that are in the data directory with the obj and mtl file.

Hope people find this useful. And SAITO it's a great lib, I've really enjoyed messing around with it. It's been a great learning experience.

MattD(polymonkey)
Re: SAITO OBJ Loader material fix
Reply #4 - May 2nd, 2008, 11:28pm
 
Hi Saito
I like this lib very much! What about a function that compiles the vertexes as a OPENGL Display list and makes all very very faster?

greetings ascorbin
Re: SAITO OBJ Loader material fix
Reply #5 - May 2nd, 2008, 11:52pm
 
I believe that someone is working on an updated version that goes way beyond mere display lists (which aren't that quick TBH) and implements vertex buffers.
Re: SAITO OBJ Loader material fix
Reply #6 - May 2nd, 2008, 11:55pm
 
We're working on it at the moment. Hopefully we'll have something to show in a few weeks. If you keep an eye on the google code page, we'll be working on it in there. Once it's fit for human consumption we'll post it up on the board.

http://code.google.com/p/saitoobjloader/

MattD
Re: SAITO OBJ Loader material fix
Reply #7 - May 3rd, 2008, 8:30pm
 
yeah hurra!
Re: SAITO OBJ Loader material fix
Reply #8 - Jun 12th, 2008, 10:18pm
 
Any updates on this?

I think a Vertex Buffer Object wrapper (or at least implementation as part of the OBJ loader) is the single most obviously needed addition to Processing. We're using OpenGL, now we just need to harness the real speed potential.

Love to see any progress you guys have made. I started a crude wrapper... but it's REALLY crude.
Re: SAITO OBJ Loader material fix
Reply #9 - Jun 13th, 2008, 12:40am
 
It's still on the radar, but day jobs are taking up all the time. I'm also having some crazy weirdness with compiling for 0136+.

We'll make sure updates get to the board as they happen. Feel free to help out if you can't wait for us.

MattD
Re: SAITO OBJ Loader material fix
Reply #10 - Jun 13th, 2008, 5:22pm
 
polymonkey wrote on Jun 13th, 2008, 12:40am:
I'm also having some crazy weirdness with compiling for 0136+.

please let us know via the bugs db what's going on.. i'd like to make 014X the default download sometime soon so we need to get things like this worked out.
Re: SAITO OBJ Loader material fix
Reply #11 - Jun 13th, 2008, 10:40pm
 
I've just posted the bugs that I've hit. BTW I love the ctrl+/ function. The new runner is awesome but it's the little things .

M
Re: SAITO OBJ Loader material fix
Reply #12 - Jul 1st, 2008, 10:43pm
 
Is it possible to animate .objs? Ive got them going using the excellent objloader but Id like a fish to "swim" for instance, or is it all static just now?

Also I see the page still has the old version so I guess the new one isnt ready yet, lookign forward it it Smiley
Re: SAITO OBJ Loader material fix
Reply #13 - Jul 1st, 2008, 11:36pm
 
You can do a model swap method of animation. For example make several obj files that are the keyframe poses of the animation. Load them into an array of obj's and on each frame draw one of the objs.

Here is a bit of example code (disclaimer it's untested, have to get to work).

The for loop is used in setup to load in the models that have consecutive file names. And the % in the draw loop is used to ensure the index never goes outside the bounds of the number of elements in the models array.

Quote:

import saito.objloader.*;
int index;

OBJModel[] model = new OBJModel[5];

void setup()
{
 size(600, 600, P3D);

 for (int i = 0; i < model.length; i ++){
    model[i] = new OBJModel(this);
    model[i].debugMode();
    model[i].load("modelName_" + i + ".obj");
 }
}

void draw()
{
 background(255);
 lights();

 model[index].draw();
 index++;
 index = index % model.length
}


In addition to this if the transition is to harsh you could create a morphing effect by moving the verts between keyframes. There is an example for getting the verts on the download site. (If you run into trouble I could hook up an example at work)

One last piece of advice. In any situation where you are dealing with lots of models the old gaming saying rings true. Less polys == runs faster.
Re: SAITO OBJ Loader material fix
Reply #14 - Jul 3rd, 2008, 1:11pm
 
Thanks for this nice hack, I will definitely try it out - I havent been making my own objs but it looks like I will probably have to to do this.

Yes the OBJs draw pretty slowly (found a skull one that is extremely slow), I keep them in point mode to speed things up, on my desktop pc they fly around but I also use a 1.1ghz laptop with linux for processing, so I usually make everything in wireframe, which I love anyway.

Pages: 1 2