I got a warning that a parts shader contains more than one part node assigned to 'default'. It doesn't 'do' anything, but it's annoying. Can I change something within TG to get this right (apart from unchecking 'show warnings')? I don't really understand it, as the 6 shader set looks like any other.
Hi Ulco,
Can you please send me a project file at jomeder@planetside.co.uk?
Regards,
Jo
Si je me trompe pas, il faut faire plusieur fois le node et de lié à tes shader que tu souhaite. ;) Essaie.
If it's an .obj I rename everything in PoseRay when I convert to avoid this annoying thing. I've never tried it, but if it's a .tgo, maybe load it in a separate instance of TG2 and rename them in the Parts Shader and resave the .tgo with a different name to avoid overwriting the original if this doesn't work. It's never really bugged me that much but if it did that's what I'd try . .. ...
It's in the part of the parts shader that you can't rename or delete (I often copy 'old' default shaders + attachments and replace the originals in a new grass or something, but the parts have to stay as they are). I found that it's the assignment of colors/materials in XFrog that has to be done right. Thanks for your suggestions, guys.
Quote from: Dune on November 04, 2011, 11:38:12 AM
It's in the part of the parts shader that you can't rename or delete (I often copy 'old' default shaders + attachments and replace the originals in a new grass or something, but the parts have to stay as they are). I found that it's the assignment of colors/materials in XFrog that has to be done right. Thanks for your suggestions, guys.
Well I just went into the Parts shader of a .tgo object and changed all the names so that for sure can be done Dune, dunno if that will solve the error messages...give 'er a try mate . .. ...
and it rendered as expected as well . .. ...
How to delete an "Object part" (does not work with the "Parts shader"):
Mark the object part->Edit->Copy (or CTRL-C) then Edit->Paste (or CTRL-V). Mark the two parts then Edit->Delete (or press DEL).
I hope this is a feature and not a bug and will not be removed in the next update.
;)
If you have it as an .obj you can load it into PoseRay and just turn off any parts you don't want and re-save with a new iteration name as well, but that is a truly useful tute Klas, thanks . .. ...
Thanks, Klas. Very handy to know that. But the initial problem was to get rid of the warnings that there was more than one part node assigned to a parts shader. And you can't change that in the object part itself where it says name, part, shader. Has to be done correctly in XFrog.
If you run your models thru Poseray there is a checkbox under .obj export that is "fix material and group names". If this is not checked Poseray will rename all material files that are similiar with a number extension of the original. It will also give the same error about "more than one part node assigned to a parts shader". I found this by accident........everybody else may already know about this............but it is news to me.
Interesting. I always take my XFrog objects directly into TG and save them as tgo after finalizing, but it might be interesting to take them through Poseray for a change. By the way, there's no way to save a .tgo as .obj, is there?
Quote from: Dune on November 07, 2011, 02:37:28 AM
Interesting. I always take my XFrog objects directly into TG and save them as tgo after finalizing, but it might be interesting to take them through Poseray for a change. By the way, there's no way to save a .tgo as .obj, is there?
Uh, yup there is..... but it saves a single mesh with no access to individual parts, sadly
Quote... but it saves a single mesh with no access to individual parts, sadly
that can be solved easily with Wings3d,if the polycount and/or the filesize is not too high.
Hey, thanks, guys. I never even noticed the other 'save as' possibilities. Very good to know.
Quote from: j meyer on November 07, 2011, 10:48:37 AM
Quote... but it saves a single mesh with no access to individual parts, sadly
that can be solved easily with Wings3d,if the polycount and/or the filesize is not too high.
Would it need to be re U/V mapped ?, as the save removes all embedded info as near as I can tell
I don't know,never checked that aspect,but what i remember from dissecting free
objects there should be no problems as long as the geometry stays intact.
Quote from: j meyer on November 07, 2011, 12:26:45 PM
I don't know,never checked that aspect,but what i remember from dissecting free
objects there should be no problems as long as the geometry stays intact.
Well I don't have Wings3D but I managed to separate trunk/branches from leaves in Imagine3D but that left the model sans U/V maps and PoseRay didn't get them back...If someone else wants to try the raw extracted .obj in Wings3D I'll send it or post it...RSVP if you are interested . .. ...
C'mon Bobby,Wings3d is free,give it a try man.
Quote from: j meyer on November 07, 2011, 02:15:00 PM
C'mon Bobby,Wings3d is free,give it a try man.
heh heh heh...tried it when I had a roommate who was enamored of it, but as a point, line, face modeler I could never adapt to the box modeling though I may have years back, but am a lot less patient than I was when I was a young sprout. At 63 I'm just trying to actually remember
what i already know . .. ...
;D Ok,that's an argument...and i got curious and tried it anyway.Seems there's more
to it than just the separating.Most likely things get a bit messed up on export(from TG2),
but to be sure more tests are required.Might take a while,though.
better than the results I got with Imagine3D in any case....I may still take a run at Wings as I need a modeler that will do U/V mapping
Meanwhile i have tested it with a simple 3 part object made in Wings3d,no problems
at all.Tg2 converts the geometry from quads to triangles,but the UV mapping is not
affected in any way.You just have to separate the parts(after the tgo to obj conversion)
again and set up the materials anew for export (that's what gives you the parts shaders in
TG2).And then in TG2 you'd have to reassign the texture images(bump,displ,spec) of course,
or do what ever is required for use in other apps.
As for problems like those shown above my guess would be that it depends on the software
the original obj file was generated with as there seem to be many different approaches for
saving/generating obj files.And some may cause problems.Like the problems you use Poseray
for.
Thanks for that, Jan. Good to know all this.
Quote from: Dune on November 07, 2011, 02:37:28 AM
Interesting. I always take my XFrog objects directly into TG and save them as tgo after finalizing, but it might be interesting to take them through Poseray for a change. By the way, there's no way to save a .tgo as .obj, is there?
I'd recommend keeping your objects in the OBJ format and saving your finalized objects as Terragen Clip files (TGC) with the original OBJ, not converting to TGO.
Would you mind explaining why that would be better, Matt? I don't always dump my obj's, but often do. I can understand it's better to have them (the obj's) as a backup, but is a tgc 'better' than a tgo?
Quote from: Matt on November 11, 2011, 10:01:37 PM
Quote from: Dune on November 07, 2011, 02:37:28 AM
Interesting. I always take my XFrog objects directly into TG and save them as tgo after finalizing, but it might be interesting to take them through Poseray for a change. By the way, there's no way to save a .tgo as .obj, is there?
I'd recommend keeping your objects in the OBJ format and saving your finalized objects as Terragen Clip files (TGC) with the original OBJ, not converting to TGO.
But you can't populate .tgc so.tgo is still necessary for pops...buuuut just had a look and was gobsmacked by the fact that a .tgo is approx 7 times the size of an .obj....I won't be converting
any more to .tgo with that knowledge in my brain. Dunno why I never checked that before . .. ...
Bobby, I've never ever seen that before. Every single .tgo I've made from an .obj is significantly much smaller than the .obj it came from. So much so that I usually replace objects with TG models to save on memory in heavy scenes. I've never seen a .tgo that was even the same size as the original model, they're always much smaller for me.
Ulco, you can also save a .tgo model as .obj from within Terragen(use the drop-down box in the save dialogue) but it won't write a .mtl file to go with it. I've yet to work out any way to get a .obj out of TG that can be used elsewhere because of the absent .mtl but you can convert any of your .tgo files to .obj format, perhaps the only way would be that you need to be skilled in modelling and be able to reassign your own texture domains to the TG written .obj in a third party modeller. You're pretty handy with the modelling yourself, I'm sure you could work it out.
dandelO, the obj file is a text file, the tgo looks like binary, so the filesize differs, but the size in memory should be the same.
Ah right, thanks, Klas. I've just always assumed that the larger the object filesize, the more resources it would take up when in use. I suppose since there's no difference in geometry between filetypes then they would use just the same resources regardless of filesize.
Cheers! :)
Quote from: dandelO on November 12, 2011, 12:14:57 PM
Ah right, thanks, Klas. I've just always assumed that the larger the object filesize, the more resources it would take up when in use...
I thought the same about image file types in the past , like that a little jpg should take less space in memory then a BMP for example .
But i was wrong . What matters is the dimension of the image and if it is 16 or 32 bit etc.
But in the 3D object aspect it is not so easy i think.
Max objects do store much more then the position of the vertices , polygons etc.
This is maybe the problem why you have to have MAX to use max objects.
The others are different too. Not sure what TGO files do contain .
And file conversion is not always easy and safe as many from us know here .
Matt could have his own reason for not recommending it.
But if you ask me any conversion could bring its problem you do not see at first.
So i would like to use the original file so far i can if i can save it with the project .
Easier and safer if you ask me.
Quote from: dandelO on November 12, 2011, 10:53:51 AM
Bobby, I've never ever seen that before. Every single .tgo I've made from an .obj is significantly much smaller than the .obj it came from. So much so that I usually replace objects with TG models to save on memory in heavy scenes. I've never seen a .tgo that was even the same size as the original model, they're always much smaller for me.
Have a look at this then...I've hi lighted one but they're all similar you'll note....maybe not as big a difference as I said previous
but math ain't my hotsuit . .. ...
D'oh.....replied before reading all the follow up posts sigh....good info Klas, gonna do a test with obj vs tgo parameters, specofically
looking at the.tgd size which is were any difference would show?
Thanks, Martin. Bobby also pointed me to saving tgo's as obj, which I didn't even notice before. I'll figure the rest out, indeed.
Quote from: Dune on November 12, 2011, 02:25:13 AM
Would you mind explaining why that would be better, Matt? I don't always dump my obj's, but often do. I can understand it's better to have them (the obj's) as a backup, but is a tgc 'better' than a tgo?
TGO has the convenience of having everything in a single package, and the file size is smaller than OBJ. However, the TGO only contains the information that Terragen was able to load from the OBJ in the first place. There may be other data in the OBJ that future versions of Terragen might be able to support which you would lose if you deleted your OBJ. Also, if you only keep the TGO, it's much more difficult to get that back into a format that you can use in other packages. You can export, but you have to rebuild all the material assignments and anything else which doesn't export. Being able to export to OBJ is there for completeness, since we already have OBJ saving capability for the purposes of exporting terrain data and so on, but it's not ideal for exporting things with material assignments. Everything that's being brought up in this thread. If your original object was in OBJ format and it loads well into Terragen, and you can save all your modifications as a TGC without destroying the OBJ, why wouldn't you?
Matt
Quote from: bobbystahr on November 12, 2011, 10:14:30 AM
But you can't populate .tgc so.tgo is still necessary for pops
That's a good point but not exactly true. You can create a population from a TGO file much easier than with an object in a clip file, that's true. But you can still populate them. You can create a population of some kind, load the clip file into the populator node and then connect the object to the populator. Or you can save yourself that step by saving a clip file of the population, instead of just the object.
Matt
Thanks, Matt!
Cool....I wasn't aware you could save a population as a clip file
Quote from: bobbystahr on November 12, 2011, 06:17:47 PM
D'oh.....replied before reading all the follow up posts sigh....good info Klas, gonna do a test with obj vs tgo parameters, specofically
looking at the.tgd size which is were any difference would show?
So it turns out that identical .tgd files with only the objects differing[tgo and obj] have the exact same file size
Quote from: bobbystahr on November 14, 2011, 03:22:13 AM
Cool....I wasn't aware you could save a population as a clip file
Yeah. A clip file really is just a collection of one or more nodes, any nodes. It's very similar to copying and pasting nodes. Just remember that whatever files your nodes reference on your hard disk need to still be there when you load the clip - it only stores the node information.
Matt
Hi Bobby,
Quote from: bobbystahr on November 14, 2011, 03:30:12 AM
So it turns out that identical .tgd files with only the objects differing[tgo and obj] have the exact same file size
The reason for that is that the .tgd file doesn't store the object data. It just records the path to the object file on your hard drive.
Technically there might be a slight difference if the OBJ file and TGO file were in different locations or had different names, giving a different length file path, but that's a very minor thing.
Regards,
Jo
Quote from: jo on November 14, 2011, 03:37:18 AM
Hi Bobby,
Quote from: bobbystahr on November 14, 2011, 03:30:12 AM
So it turns out that identical .tgd files with only the objects differing[tgo and obj] have the exact same file size
The reason for that is that the .tgd file doesn't store the object data. It just records the path to the object file on your hard drive.
Technically there might be a slight difference if the OBJ file and TGO file were in different locations or had different names, giving a different length file path, but that's a very minor thing.
Regards,
Jo
Ah Ha....a light comes on with a dim memory of the efficiency of saving whole scenes by paths not geometry.
Imagine3D does just that but since TGxxx arrived I've not dipped into Imagine but to build to convert for
Terragen....LOL and I guess it slipped what's left of my mind . . ...