Snorky wants me to translate a message for him:
"I wanted to know how the external meshes are handled: my worry has always been to create my own object library (in my free time), but mixing "classic" components with mesh-linked components is not too convenient, in my opinion.We'd need a dedicated library, with some kind of procedure which could automatize the skp_dummy-ext_mesh linking and make it more evident.
..it could use the same structure as the "material preset" (which has been a little abandoned, but which I find extremely useful), and be located in a sub-folder inside plugins/sketchup.."
SkIndigo 3.0.14 (3.0 Stable)
Re: SkIndigo 3.0.14 (3.0 Stable)
Sorry, but I'm not exactly sure what you mean. Let me explain my workflow for using external meshes from Xfrog:Pibuz wrote:Snorky wants me to translate a message for him:
"I wanted to know how the external meshes are handled: my worry has always been to create my own object library (in my free time), but mixing "classic" components with mesh-linked components is not too convenient, in my opinion.We'd need a dedicated library, with some kind of procedure which could automatize the skp_dummy-ext_mesh linking and make it more evident.
..it could use the same structure as the "material preset" (which has been a little abandoned, but which I find extremely useful), and be located in a sub-folder inside plugins/sketchup.."
1) Start a new SKP file.
2) Model the dummy component, make it a component, and name the definition "EXT_mycompname"
3) Set the description of the component to the path of the Xfrog OBJ file.
4) Create the materials of the OBJ file within SketchUp with identical names. For example, if the OBJ file contains a material called 'Bark', make sure you create a material inside SketchUp named 'Bark'. I have a custom script that does this automatically for me. It is based on[ur=http://forums.sketchucation.com/viewtopic.php?t=20584l] TIG's OBJ import script[/url] but I changed it so it does not import the mesh, just the materials.
5) If I'm creating a tree, I also create a 'billboard material' which is a 2D image of the tree which I paint onto the dummy component.
6) Another thing you need to do is make sure all the OBJ materials are 'used' in the dummy component. In my case, I paint the edges of the dummy component with the OBJ materials.
7) When I'm done, I do a test render to make sure everything is working.
8) Next, right-click on the dummy component and 'Save As..' into my component library. Then, I can use the external mesh in any scene just by dragging and dropping it from my component browser window.
Hopefully, I can make this workflow easier in the next SkIndigo version.
Re: SkIndigo 3.0.14 (3.0 Stable)
Trying to get this to work on a mac with little success. I think I'd need to feed it the file locations differently. Any tips as to how I might get that to work?Whaat wrote:Sorry, but I'm not exactly sure what you mean. Let me explain my workflow for using external meshes from Xfrog:
Re: SkIndigo 3.0.14 (3.0 Stable)
OKAY, I take back all those mean things I said. It works just fine on a mac. I was just being an idiot.
Now it's just a matter of getting the .obj file to scale correctly! I've got blades of grass that are 10 feet tall.
Now it's just a matter of getting the .obj file to scale correctly! I've got blades of grass that are 10 feet tall.
Re: SkIndigo 3.0.14 (3.0 Stable)
This is the step that's the tripping hazard for me. For some reason, SKP is stripping the names off of the .obj and naming the textures "material_0" "material_1" "material_2" etc, which isn't a problem when only using one tree, but when using multiple trees, the textures get imported as new numbers when they start stacking up, so I get redwood trees with birch bark and oak leaves.Whaat wrote:4) Create the materials of the OBJ file within SketchUp with identical names. For example, if the OBJ file contains a material called 'Bark', make sure you create a material inside SketchUp named 'Bark'. I have a custom script that does this automatically for me. It is based on[ur=http://forums.sketchucation.com/viewtopic.php?t=20584l] TIG's OBJ import script[/url] but I changed it so it does not import the mesh, just the materials.
I think the problem may be that when I use Meshlab to fix the scale of the mesh, it also creates a .mtl file to hold the texture information, so when I export from sketchup to indigo, it knows there should be textures, but it doesn't know their names, so it just uses default material names, or something along those lines.
Anyways, it works great except for that little problem! I'd need to find a Meshlab fix to integrate the example.mtj.obj files with the .obj file, or some other way of managing the scale of the meshes when they go to indigo.
Re: SkIndigo 3.0.14 (3.0 Stable)
Yes, I know exactly what you mean. This can cause big headaches. I have had to go and manually edit by Xfrog OBJ files to make sure that different OBJ files are not using the same material names. Unfortunately, this is something that SkIndigo will not be able to do automatically. You either need to open your external mesh file and edit the names (in case of OBJ) or open it in another app (say Blender) and rename all the materials to make sure they are unique.Frutiger wrote:This is the step that's the tripping hazard for me. For some reason, SKP is stripping the names off of the .obj and naming the textures "material_0" "material_1" "material_2" etc, which isn't a problem when only using one tree, but when using multiple trees, the textures get imported as new numbers when they start stacking up, so I get redwood trees with birch bark and oak leaves.Whaat wrote:4) Create the materials of the OBJ file within SketchUp with identical names. For example, if the OBJ file contains a material called 'Bark', make sure you create a material inside SketchUp named 'Bark'. I have a custom script that does this automatically for me. It is based on[ur=http://forums.sketchucation.com/viewtopic.php?t=20584l] TIG's OBJ import script[/url] but I changed it so it does not import the mesh, just the materials.
I think the problem may be that when I use Meshlab to fix the scale of the mesh, it also creates a .mtl file to hold the texture information, so when I export from sketchup to indigo, it knows there should be textures, but it doesn't know their names, so it just uses default material names, or something along those lines.
Anyways, it works great except for that little problem! I'd need to find a Meshlab fix to integrate the example.mtj.obj files with the .obj file, or some other way of managing the scale of the meshes when they go to indigo.
Just so you now, the MTL file is ignored by SkIndigo and Indigo. Indigo will look for the material name inside the OBJ file, not the MTL file.
Re: SkIndigo 3.0.14 (3.0 Stable)
I've been goin for xfrog manual renaming, but it's a very troubly process.
I mean, not so practical..
I tried checking the obj file too, but renaming things there cased some other linked errors, so I went for the xfrog process..
I mean, not so practical..
I tried checking the obj file too, but renaming things there cased some other linked errors, so I went for the xfrog process..
Re: SkIndigo 3.0.14 (3.0 Stable)
..another srange thing happen when I import some already-created trees: if there is some specific suffix, say "copy_2" or similar, sketchup doesn't import the material, and automatically assigns the material "copy" (already present in the model) to the faces with the "copy_2" previously attached.
So I worked a lot to create trees in separated files, but when I import some of them into the same skp, some mats mess up a little, and Indigo doesn't find the obj mat anymore, so I have to re-create it..
Did anybody else experience this too?
So I worked a lot to create trees in separated files, but when I import some of them into the same skp, some mats mess up a little, and Indigo doesn't find the obj mat anymore, so I have to re-create it..
Did anybody else experience this too?
Who is online
Users browsing this forum: No registered users and 2 guests