I know there are a lot of threads about this. I am importing an OBJ model in TG3 (using OBJ reader) and the textures are not showing when I go to render. Surfaces are are either all white or all black. There is indeed an mtl file and Lightwave is finding all of the textures through this file when I load the model into that application. It is an ASCII file and it seems to have all of the absolute paths to the textures.
Hi,
Can you post the MTL file for us to look at?
Regards,
Jo
Here is the latest one. I'm not getting any errors on the import like I was before I forgot to copy the mtl file into the same directory as the obj file. But the textures are still not there on the object.
This is what I am seeing in the render (see pic #1 below). The roof and base come out black while the log "siding" comes out white. In the model, the roof is reddish-brown and base is a textured medium brown wood patternn while the siding is a light amber texture like pine coated with varnish (see pic #2 below).
[attach=1]
[attach=2]
Hi,
The paths in the MTL file are not absolute paths, they're relative paths. I don't know enough about your drive setup to know whether these files should be found or not, or in fact whether TG would find files from paths like this (I will need to check next time I'm on Windows).
An absolute path would look like:
E:\Animation
whereas what you have is:
E:Animation
It should work if the paths in the MTL file were full absolute paths.
Regards,
Jo
I looked at the paths and assumed that the '/' was implied. Besides, Windows uses the '\' instead of '/' so it stood to reason that the paths had to be edited by the application during loading anyway. Since Ligthtwave was finding the images okay, I assumed that it was the correct format. It may be the case that different vendors interpret "standards" different ways. And the current directory for E: may be initialized to something different in LW than in TG. This, I believe, is the directory that the object file is in.
I'll edit the mtl file and see if TG finds the images. But, keep in mind that TG is not reporting any erros when loading the file. This may be a bug. Perhaps it is generating errors but is not automatically bringing the error reporting panel up. I'll have to do some research on how to bring it up manually.
<<<<<<<<<<<<<<< LATER >>>>>>>>>>>>>>>>>
I edited the paths in the mtl file to be absolute according to UNIX rules (with slash leading the path as in "E:\path..."). The model is still not textured when rendering. Also, looking at the error panel using View/Errors and Warnings shows there to be no errors. If TG can't find the files then do you not think that it should report an error in the error panel?
Hi,
I'll check out the path situation on Windows today. It may be a bug on our part, but it seems like it should work. I've never come across paths like that before myself. The paths in your file are ones which are relative to the current working directory of the specified drive (E). That makes them a little bit fragile because you don't always know what the current working directory might be. It could be that Lightwave sets the working directory which is why it works. I can only guess without knowing the layout of your filesystem though.
Windows can use "\" or "/" as a path separator.
If TG can't find the images it should be reporting it. You can check to see if it's loading the images using the Project Assets window. You can open this using the Show Project Assets item in the Project menu. There is documentation here:
http://www.planetside.co.uk/wiki/index.php?title=Project_Assets_Window
There are a couple of ways to open the Errors and Warnings window. You can click on the Errors and Warnings panel at the bottom right of the main window. It has the Error and Warning icons. You can tell if there are any errors or warnings because there will be the number of them next to the appropriate icon. You can also open the Errors and Warnings window from the View menu.
Regards,
Jo
I looked in the assets panel and it is showing none of the textures that are part of the model. If I click on "Only show assets with problems" then the list goes empty. So TG is not loading them but it is not reporting the problem. Also, early on I forgot to copy the mtl file to the same directory where the obj is designated in the Obj reader node. It did report an error until I placed a copy of the file there. So that assures me that TG should be reading that file. Also, LW loads and displays the edited version of the mtl file correctly so I didn't do any damage when I edited it.
Now that I know that the mtl file is ASCII and, therefore editable, I'm next going to put one or more of the image files into the same directory with the obj. I'll then modify the mtl file so that it looks locally. That's the way I have done all of the plant models and it seems TG doesn't find the files unless I put them in the same directory. I have done this before for the cabin model but I didn't edit the paths in the mtl file. I'll let you know how things go.
It seems that some 3D applications impose a file organization on you that aren't very efficient storage-wise. For example, if I want to use the LW rendering system called "ScreamerNet" then I have to replicate all of the assets into each project's file system. I guess, though, that this tends to buffer the projects against the possibility of one of the assets being modified for benefit of another project and thus "breaking" the project. Looks like if I ever want to use my render farm for LW renders, I'll have to organize my project files differently.
<<<<<<<<<< UPDATE >>>>>>>>>>
I changed all of the path names in the mtl file for one of the assets to look into the same directory were the obj is located. Actually, I had copied all of the images some time ago so they were already there. TG does not load or display the textures. Apparently, Lightwave assumes paths are all absolute regardless of whether there is a leading '/' or not in the path name. So I removed the path and only left the drive designator and the file name (in the form E:file.nam). Lightwave does not find them and complains of file not found. This tells me that Lightwave must be looking in the drive's root directory for them. I conclude that all path names in the mtl file are always interpreted as being absolute path names by LW.
Come to think of it, all of the models I have been using successfully are TGO's. I had stopped using OBJ's (and LWO's before that) because I could never get the textures to show. I would convert my OBJ's to TGO's if I had a way to do it. Using the method Dune pointed out in another thread won't do. The textures are already gone by the time I get the model into TG. It seems that the method of right-clicking on the node and saving an obj doesn't produce an mtl file either. I tried it and there is no matching mtl file. It seems that I have no way to create my own textured models that are usable by TG at this point in time.
Hi,
Something isn't right. This stuff does work. I frequently use OBJ models. I think the best solution here is that you package up the model with all it's files and send it to me so I can check it out. I should be able to figure out what's happening and help you avoid these problems in the future. My email address is:
jomeder@planetside.co.uk
You can send me a zip file directly if it's not more than 10 MB, otherwise a link to download it would be great.
Regards,
Jo
Sorry to stick my nose in but I'm an old light wave user.
Check that your obj has a UV map. Also that all polygons have are assigned to a UV map.
There was an old bug in the Lightwave OBJ exporter where if a single Polygon was not assigned a UV map it would delete the UV map.
As Mash said there was a bug in the OBJ exporter.Not sure in which version.
Because of this i did not bother to export from Lightwave OBJ files.
Instead i open the LWO files directly in Poseray and export from there my OBJ files.
Since Poseray is very TG friendly this would be my way anyway.
Quote from: mash on April 09, 2014, 09:38:45 PMCheck that your obj has a UV map. Also that all polygons have are assigned to a UV map. There was an old bug in the Lightwave OBJ exporter where if a single Polygon was not assigned a UV map it would delete the UV map.
That may be the problem. I am using planar texturing, not UV mapping. I prefer planar mapping in this case because it automatically repeats seamless patterns along the plane and it is far less work to texture flat surfaces than to use UV mapping. If TG does not support planar mapping then it probably explains the problem. But the mtl file that I posted should indicate the mapping method I used but it may be encoded as a number in one of the entries. I've done UV mapping before so I will give it a try.
<<<<<<<<<< UPDATE >>>>>>>>>>
I had trouble openning this file in my newest version of Lightwave because Windows would not let me associate the file type with the executable. It would run the old version instead and claim I had no license. So I uninstalled two older versions of Lightwave (never had this trouble before) and now Windows won't let me associate the obj file type with anything but Modo. So the only way I can open it with Lightwave is to drop the obj's icon onto a short cut pointing to Lightwave.
I can finally open obj's with Lightwave and I see that the textures are now UV mapped. So it must be the obj format that doesn't support planar mapping and so the Lightwave export is what created the UV map. So next, to address the issue that mash brings up, if I reload the obj model with Lightwave I see that the UV maps were not deleted because all polygons are assigned and everything looks as it should in Lightwave. But the issue still remains that TG doesn't load the textures and doesn't report that there is a problem.
There has to be a difference in the way LW and TG interpret the same obj file. But TG doesn't report a problem so there is at least one bug in TG.
Nearly every thread of this type seems to get a Poseray mention, so here goes.....
A nice feature with Poseray is you can correct your model's normals on the Groups tab. On the Materials tab, you can check each part to see if it's getting the correct material assigned. You may get a warning at the bottom of the window stating "x warnings -> Material (roofSurface......". If that happens, you can go to the "Tools" submenu under the Materials tab and select "Find all missing maps". Then you can set up the search paths and click 'Search". If you set up your search paths correctly, it should find all the maps and give you zero warnings.
One other thing. When you export your Poseray processed object, there's an option to "Include the file paths to the image maps" or what I generally use "Copy all maps to the same directory"
Quote from: jaf on April 10, 2014, 01:00:47 PMA nice feature with Poseray is...
I can't believe the problem I just had. I went to download PoseRay and it said my browser is out of date. I updated all of my software about six months ago. I understand that IE6 is probably too old but 9? I'm updating windows now...
If you have Modo try to apply a UV map there and then export it as a .OBJ or maybe try an FBX file.
I thinks Modo's OBJ exporter may be a bit more up to date than the Lightwave one.
Unfortunately OBJ is not a very precise "standard", so these kinds of problems do sometimes occur. But as Jo noted, many of us do use OBJs all the time and don't run into these issues. If I'm understanding correctly, these objects are things *you* created in Lightwave, so it sounds more like a difference between LW's OBJ export and TG's OBJ import, their respective handling of the OBJ format. I do think sending an example non-working object to Jo is probably best, but if you just want to fix the problem ASAP, I have to echo the suggestion to try Poseray (which it seems you're now doing). It's very possible it will just take care of whatever issues are causing this.
- Oshyan
After studying it a while I think I am closer to understand what is going on. This is very interesting. If I load my original LWO file and export it to OBJ then load it into Modo, the textures display correctly. If I then export it from Modo into yet another OBJ then load it into either Modo or LW then the model still displays correctly in both applications. This tells me that neither the LW or Modo exporters or importers are broken. Everything works until you try to load it into TG. That's where it breaks.
There is something about the obj file that TG doesn't like. I suspected it was an innovative technique that both Modo and Lightwave use but I tested it and it must be something else. But I will put the discussion in any way for any one who is interested.
Now here is the theory I had: According to my understanding, UV maps spread a mesh across the image and specify what part of that image is projected onto each polygon. Most likely in its original definition, polygons must be smaller than the image so that the UV coordinates assigned to each vertex must fall onto the image somewhere. But this technique is limited and incapable of applying an image that is smaller than one of the polygons. Someone (whether it was one of the Modo, LW or other 3D SW development teams) figured out how to apply the same small image repeatedly across a very large polygon. The way this is done is by placing the UV coordinates far outside the limits of the image itself. For example, say a UV square is four times the size of the image you are using. This means that the image is repeated across the polygon to fill the whole thing four times. This is an ingenious method to get UV mapping to efficiently use a smaller image to fill a large area. I suspect that some companies do not honor this innovative extension to the UV mapping method. When the image and UV map are loaded it sees that UV coordinates lie outside the image and interpret it as a violation. I hypothesized that TG does this and just tosses it out. But I edited the UV map in Modo so that all UV coordinates fall inside the image. After saving it and reloading with both Modo and LW the texture is applied correctly. When I load the model into TG the texture was gone and the image was not in among the assets.
So, in conclusion, there is something about the OBJ file (other than UV coordinates outside the image) that TG doesn't like. I guess my next course of action is to either download PoseRay and see what it can do or face the arduous process of creating UV maps in Modo from scratch. Planar mapping of seamless patterns is so much easier than creating UV maps. I guess in this case I can join Badger and cry about having to use them.
Hi,
I sent you an email a bit earlier today. The file you sent me loads fine on Windows and the Mac. I was wondering if it also works for you if load the same thing you sent me.
Regards,
Jo
QuoteI guess in this case I can join Badger and cry about having to use them
Yes, feel your hatred grow. Let it make you stronger. Join us! Be one of us! :P
Quote from: Oshyan on April 11, 2014, 12:21:14 AM
Unfortunately OBJ is not a very precise "standard", so these kinds of problems do sometimes occur. But as Jo noted, many of us do use OBJs all the time and don't run into these issues. If I'm understanding correctly, these objects are things *you* created in Lightwave, so it sounds more like a difference between LW's OBJ export and TG's OBJ import, their respective handling of the OBJ format. I do think sending an example non-working object to Jo is probably best, but if you just want to fix the problem ASAP, I have to echo the suggestion to try Poseray (which it seems you're now doing). It's very possible it will just take care of whatever issues are causing this.
You are correct. In light of the fact that Modo was developed by some of Lightwave's original developers, it stands to reason that they carried over the same interpretation of the obj format into their new company and that is why they interoperate so well together. Other applications may not mesh so well. I did send an (almost trivial) example non-working object and TG scene to Jo along with assets.
Thank you for treating your customers so well. Planetside is an excellent company!
Quote from: jo on April 11, 2014, 01:18:16 AMI sent you an email a bit earlier today. The file you sent me loads fine on Windows and the Mac. I was wondering if it also works for you if load the same thing you sent me.
Do I understand you correctly that the textures are displaying correctly in TG on your machine? If that is the case then there has to be something different (i.e. wrong) with my installation. The NoTexture.tif image shows you what I am seeing.
[LATER]
I just tried loading what I sent you and this time the cube is all black.
Hi,
I've attached what I get. This is rendered on the Mac but I got the same results on Windows. I think it comes down to those slightly weird relative paths in the file. I need to set up a test of my own to try and replicate them to fully understand what's going on.
TG does a pretty comprehensive search for image files specified in MTL files, because there are so many variations of how paths are specified. On my machines the files are being found because one of the searches TG does is to look in the same folder as the MTL file for a file with a matching name, disregarding the rest of the file path. Something you might try with the files you sent me is to open the MTL file in a text editor and change the lines that look like this:
map_Kd E:Greenworks/SimpleBox/RedPlaidTableclothTexture.png
to this:
map_Kd RedPlaidTableclothTexture.png
and then try importing the OBJ again. I would be pretty surprised if that didn't work.
When I get a chance I'll try setting up things on Windows to use relative paths like the MTL file uses and see what happens.
Regards,
Jo
Okay. I think my problem is solved. In my mind, exiting TG and then rerunning it was forcing TG to reload the model. But this is not so. TG "loads" the model and, apparently stores object along with the scene file when you save it. So simply rerunning the scene containing an instance of the object means that TG never looks at the mtl file again. You have to delete the object within TG and then reinsert it again. To be safe, after deleting the object from TG I inserted a different version of the object from a different file and the textures show up properly. I then went back and did the same thing using the absolute paths (with preceding slashes) and the textures show up properly. In the original cabin scene, I didn't want to actually delete the object because I would have lost all of the orientation parameters associated with positioning the object. And I didn't want to insert another instance of the object to copy orientation parameters over before deleting the first instance being afraid that TG would recognize it was coming from the same file and use cached parameters instead of forcing a reload of the same object. So I exited TGand reran it thinking that it would reload the object. But it does not. Now I think I understand what I was doing wrong. My mental model of that part of TG was flawed.
Another thing this clarifies is, since the object is not reloaded simply by rerunning a TG scene that already contains a non-textured object, it stands to reason that an error message would not be generated because a "reload" of the object isn't being done. But I did force a reload of an object that has an mtl file with the absolute paths generated by Lightwave that lack a preceding slash in the path name. TG does not find the image files but also does not report any error. So when I originally loaded the object that had an mtl file with absolute path names that needed to be manually repaired, TG just threw the textures out and recorded that there aren't any textures associated with the object. My TG scene has been carrying that same object through all my tests because I didn't actually delete and reload the object during the whole process.
From now on, after I have generated an obj file using Lightwave or Modo, I will have to edit the preceding slashes into the mtl texture file path names before I insert the object into the TG scene. If I remember to do this I thing I will be okay. This may even clear up a mystery problem that some TG users had long ago and have given up on Lightwave or Modo altogether for model creation thinking that they are generating flawed obj files when they are probably not. Editing the mtl files is really pretty easy. It just has to be done if you want to use either Lightwave or Modo to make your own models.
Problem solved and thanks all for the support. You were all great!
A question I have for Jo is: "If you don't delete the object from the scene I sent you but you do edit the mtl file in the way you describe (file only, no path) then do you see the untextured model when you run TG as I did?" If so then it clarifies things a bit more for me.
I rendered the cabin scene and it looks beautiful. But my problems are still not over. When I first load the scene with the object, I do not get any errors or warnings. But when I render then I get 31 warnings that say: "Part shader 01 contains more than one part node assigned to 'Surface Name'".
I would like to understand what is going on but I still may need to pursue the PoseRay option as others have pointed out. Even after updating my browser to IE10 the PoseRay downloader still complains that my browser is out of date and refuses to go any further in the process. I guess I will force an update to IE11 and see what happens.
Quote from: PabloMack on April 11, 2014, 10:43:24 AM
I rendered the cabin scene and it looks beautiful. But my problems are still not over. When I first load the scene with the object, I do not get any errors or warnings. But when I render then I get 31 warnings that say: "Part shader 01 contains more than one part node assigned to 'Surface Name'".
I would like to understand what is going on but I still may need to pursue the PoseRay option as others have pointed out. Even after updating my browser to IE10 the PoseRay downloader still complains that my browser is out of date and refuses to go any further in the process. I guess I will force an update to IE11 and see what happens.
I use GoogleChrome and have no probs with PoseRay dl's. Does that error message have any impact on the rendered image?...I sometimes get those and just ignore them as they don't seem to impact the final image.
Quote from: bobbystahr on April 11, 2014, 12:32:21 PMI use GoogleChrome and have no probs with PoseRay dl's. Does that error message have any impact on the rendered image?...I sometimes get those and just ignore them as they don't seem to impact the final image.
Here's how I look at having a single big corporation having too much control over my life. Microsoft has control of my computer. Google (arguably) has control of my personal information on the Internet. I use Google search a lot and I have a lot on YouTube. So, if I were to start using Chrome, then Google would have control over both my computer and my personal information on the Internet. I'm not going to let that happen. Because Microsoft and Google are big rivals, I draw the line of control at the network interface. And because Google is the looming monster on the horizon with Android threatening to obsolete both Windows and the Mac, I prefer to draw the lines of control where I still have some control. The very fact that the latest IE does not seem to qualify for downloading when even very very old versions of Windows have plenty of downloading capability sends up a red flag. I suspect it is Google working underhandedly and unethically behind the scenes to wrest control of my computer out of the hands of their rival. To me, that is not just possible, it is probable.
What I think I will do with that issue is to install Chrome on one of the computers that I only use for special purposes. But if the download looks at me funny then I will wipe that computer clean and reinstall everything. It wasn't very long ago that I installed a bunch of malware in a process in which I thought I was installing Adobe Reader. That really pissed me off. It took me the better part of a day to wipe everything and reinstall everything on that computer again. If that had happened on my main system it would have been a disaster. If all I can do is install that utility on a rarely used computer to make sure it doesn't do something like that to my main system I will. Its the malware that doesn't present itself that I have most to worry about. Some installers use the Internet to download the resources during the install.
That said, the messages in the error panel are only warnings. So far I have not noticed any problems with the renders so your assertion appears to be correct.
Quote from: PabloMack on April 11, 2014, 01:17:26 PM
To me, that is not just possible, it is probable.
That said, the messages in the error panel are only warnings. So far I have not noticed any problems with the renders so your assertion appears to be correct.
re: probable...I have days I feel like that as well...I just accepted the mark of the beast as a lot of my music friends use gmail...I use as little M$ as I can get away with and am a few more quirks from Red Hatting the whole shebang...I'd get a mac but am not that rich...
I have little problem with malware since I started using the open source ClamWin antivirus...got a trojan denial of service and couldn't get online to find a fix so after 2 days of not being able to upload my auto update they snuck in around the trojan, gave me a new version which I dl'd and installed and bye bye trojan...smart program. They also make a mac flavour.
Try Chrome on a special comp anyway...it's the fastest, most reliable browser I've ever used; and kind cool once y' get used to the minimal interface...
Quote from: bobbystahr on April 11, 2014, 01:53:17 PM...I just accepted the mark of the beast as a lot of my music friends use gmail...
You made me laugh. I have heard of many people having gmail but I have never thought of it in that context. I guess it never entered my radar screen. Probably back in the days when the Internet was just getting to its feet, the old folgies probably had such notions about Yahoo, gmail and WebCrawler. Anyway, there are probably a lot of people who never even heard of "the mark of the beast" outside of recent popular scifi/horror films. Personally, I grew up in an environment where my nose was rubbed in apocalyptic doctrine and teachings almost every day. My mother (God rest her soul) just passed away a month ago today. But the memories will stay with me...until...I guess until I get Alzheimers or a Mack truck; whichever gets me first. ;)
P.S. Apologies to Europeans for the American idiom who have never heard of a Mack Truck. Please substitute "Leyland Lorry" and, at least the British will know what I am talking about. We often use the expression "being hit by a Mack Truck" as a pretty sure way to die. http://en.wikipedia.org/wiki/Mack_Trucks
Quote from: PabloMack on April 11, 2014, 04:14:26 PM
Quote from: bobbystahr on April 11, 2014, 01:53:17 PM...I just accepted the mark of the beast as a lot of my music friends use gmail...
You made me laugh.
Anyway, there are probably a lot of people who never even heard of "the mark of the beast" outside of recent popular scifi/horror films. Personally, I grew up in an environment where my nose was rubbed in apocalyptic doctrine and teachings almost every day.
My mother (God rest her soul) just passed away a month ago today. But the memories will stay with me...until...I guess until I get Alzheimers or a Mack truck; whichever gets me first. ;)
"In dark times make light of
IT" is my current motto so I'm happy to incite levity
I grew up Pentecostal my self;
Pente-
Coastal now, heh heh heh at least till I get a working mac....
Mine passed a decade gone now but still inspires me to greater heights...
Terragen loads the MTL file once, yes, but the "object" (the actual geometry) IS loaded every time you either load the scene or exit and open Terragen. The MTL file is loaded once and converted to Terragen's native node interpretation of what it finds in the MTL. So IF you then save that TGD file and re-load it, any changes to the MTL of the source object will not be recognized unless you delete and reload the MTL. This allows Terragen to preserve any changes you make to the texturing and generally to the nodes overall, which is a good thing. But I can understand how it creates some confusion. Probably a specific "reload material definitions from disk" or "from MTL" would be good.
Re: browser, why not try Firefox? A lot more privacy-oriented and less problematic than Chrome in that regard (though I use both).
- Oshyan
Firefox is my favorite!
Yep. If I get another browser it will probably be Firefox.
Quote from: Oshyan on April 12, 2014, 04:57:28 PMBut I can understand how it creates some confusion.
I want you to know that I'm not complaining. Writing things out helps to understand the logic so I am just pounding it into my brain for later reference. I appreciate all of the good info.
Pablo